A COMPARISON OF HARDWARE DESCRIPTION LANGUAGES 


Prepared by 
SAJJAN G. SHIVA 

Department of Computer and Information Science^ 


Final Technical Report 


October 1978 


Grant NSG-8057 


"Evaluation of Digital System Design Languages” 
George C. Marshall Space Flight Center 
National Aeronautics and Space Administration 


Huntsville, Alabama 



, {BASA-CS-157762) A CCMPASJSOB OF HAEBHAEF B78-33788 , 

} DESCRIPTION lANGDAGES Final Beport CAlabaaia | 

I A S fl Univ., Huntsville.) 115 p HC A06/HF ' 

^0^ CSCX 09B Onclas ‘ 

P ^ . .... . . G3/61 3378_1 ' 


’reproduced by' ' — ; i 

! NATIONAL TECHNICAL I 

j INFORMATION SERVICE ' 

U.S DEPARTMENT OF COMMERCE I 

SPRINGFIELD, VA. 22161 1 


Alabama Agricultural and Mechanical University 

SCHOOL OF TECHNOLOGY 
HUNTSVILLE, ALABAMA 



A COMPARISON OF HARDWARE DESCRIPTION LANGUAGES 


Prepared by 
SAJJAN G. SHIVA 

Department of Computer and Information Sciences 
Alabama A & M University 
Normal, AL 35762 


Final Technical Report 
October 1978 


Grant NSG-8057 

"Evaluation of Digital System Design Languages" 
George C. Marshall Space Flight Center 
National Aeronautical and’ Space Administration 
Huntsville, Alabama 


Submitted by; 


(i . 


Saj^an G. Shiva 
Principal Investigator 


j. 



FOREWORD 


This is a technical sioimnary of the research work con- 
ducted since October 1, 1977 by the Alabama A & M University 
towards the fulfillment of Grant NSG-8057, from the George C. 
Marshall Space Flight Center, Huntsville, Alabama. The NASA 
Technical officer for this grant is Mr. John M. Gould, 
Electronics and Control Laboratory. 
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A COMPARISON OF HARDWARE DESCRIPTION LANGUAGES 


Sajjan G. Shiva 


ABSTRACT 


Several high level languages have evolved over the past 
few years to describe and simulate the structure and behavior 
of digital systems, on digital computers. The characteristics 
of the four prominent languages (CDL, DDL, AHPL, ISP) are sxrni- 
marized. A criterion for selecting a suitable HDL for use in 
an automatic Integrated Circuit design environment is 
provided. 


Ill 



TABLE OP CONTENTS 


LIST OF FIGURES VI 

1 . INTRODUCTION 1 

2. COMPUTER DESIGN LANGUAGE 5 

2.1 Syntax Rules 6 

2.2 Declaration Statements 7 

2 . 3 Continuations 1 3 

2.4 Comment Cards 13 

2.5 Operators 14 

2.6 Micro Statements 16 

2 . 7 Switch Statements 1 7 

2.8 Labeled Statements 17 

2.9 End Statement 18 

2.10 Card Format 1 8 

2.11 Trans lator 1 8 

2.12 Simulator 1 9 

2.13 Design Examples 24 

2.14 Extensions 37 

3. INSTRUCTION SET PROCESSOR 42 

3.1 Syntax Rules 43 

3.2 Operators 44 

3.3 Arithmetic Representations 44 

3.4 Descriptions 45 

3.5 Behavioral Expressions 51 

3.6 Qualifiers 59 

3.7 ISPS Definitions 60 

3.8 Predeclared Entities 61 

3.9 Reserved Keywords and Identifiers 62 

3.10 The Complete Minicomputer 63 

3.11 ISPS Simulator 66 


IV 



4. HARDWARE PROGRAMMING LANGUAGE 69 

4.1 Syntax Rules 70 

4.2 Declarations 71 

4.3 Control Sequence 71 

4.4 Coimbinatxonal Logic Unirs 72 

4.5 Comments 73 

4.6 Simulator 73 

4.7 Design Example 74 

5. DIGITAL SYSTEM DESIGN LANGUAGE 82 

5.1 Syntax Rules 83 

5.2 Declaration Statements 83 

5.3 Operations 85 

5.4 IF-Values Clause 88 

5.5 Identifxer 89 

5.6 Operator Declaration 90 

5.7 State Declaration 91 

5.8 Automaton and System Declarations 92 

5.9 Advanced Features r 96 

5.10 Translator 9 6 

5.11 Simulator 96 

5.12 Desxgn Example 98 

6. COMPARISON 101 

7. CONCLUSIONS 104 

REFERENCES 106 


V 



LIST OF FIGURES 


2-1 Serial Twos Complementer 25 

2-2 A Sequential Circuit 30 

2-3 Variable Timer 35 

2-4 CDL Description of Variable Timer 36 

2-5 A Typical Cell of the Ripple Counter 38 

2-6 A3 Stage Ripple Counter 38 

4-1 Multiplier Block Diagram 75 

4-2 HPSIM Program Input File for the Multiplier 76 

4-3 HPSIM Output Listing for the Multiplier 76 

4-4 HPCOM Output 79 

4-5 HPCOM Output 80 

4- 6 Multiplier 81 

5- 1 DDL Operators 86 


VI 



1 . INTRODUCTION 


Any digital system can be described in the following six 
levels of complexity: 

1) Algorithmic level which specifies only the algorithm 
used by the hardware for the problem solution; 

2) Processor, memory, switch. (PMS) level which describes 
the system in terms of processing units, memory com- 
ponents f peripherals and switching networks ; 

3) Instructional level (programming level) where the in- 
structions and their interpretation rules are specified; 

4) Register transfer level where the registers are system 
elements and the data transfer between these registers 
are specified according to some rule; 

5) Switching circuit level where the system structure con- 
sists of an interconnection of gates and flip-flops and 
the behavior is given by a set of Boolean equations; and 

6) Circuit level where the gates and flip-flops are replaced 
by the circuit elements such as transistors, diodes, re- 
sistors etc. 

Logic diagrams. Boolean equations and programming lan- 
guages have been used as the media of description. The 
complexity of logic diagrams and Boolean equations increases 
as the system complexity increases and are not suitable for 
describing the hardware to a computer in a design automation 
environment, although the recent advances in computer graphics 
might make the input of logic diagrams to a computer easier. 
The common programming languages do not have all the features 
required to describe the hardware. Hardware description 
languages (HDL) evolved as a solution. An HDL is similar to 
any other high level programming language and makes the hard- 
ware designer's task easier by providing a means of: 
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1) Precise yet concise description of the system; 

2) Convenient docximentation to generate users manuals, 
service manuals, etc; 

3) Inputting the sysrem description into a computer, for 
simulation and design verification at various levels of 
detail; 

4) Software generation at the preprototype level, thus 
bridging the hardware/software development time gap; 

5) Incorporating design changes and corresponding changes 
in documentation, efficiently; 

6) Designer/user (teacher /student) communication interface 
at the desired level of complexity. 

Several HDL's have been reported [1-30] , The translators 
and simulators are also written for some of these HDL's. The 
tendency has been to invent a new HDL to suit a particular 
design automation environment, basically due to the difficulty 
in transporting the translators and simulators on to the new 
computing systems and extending these to accomodate the re- 
quirements of the new design environment. Attempts to stand- 
ar di ze HDL ' s are underway . 

Hardware Description Languages are designed to describe 
both the structural and behavioral characteristics of a dig- 
ital system, to a computer. The fundamental properties of 
hardware systems and the art of hardware design process 
dictate the essential features of an HDL. For an HDL to be a 
useful design tool it has to possess the following proper- 
ties : 

1 ) It has to have a natural way of describing the paral- 
lelism, nonrecursive nature and timing issues in digital 
hardware . 

2) The structure and control parts of the hardware should be 
easily described and preferably the description of the 
two parts be separated so that a user interested in the 
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behavior of the system need not concern himself with the 
structure of the system. This also provides the flexi- 
bility to use hardware, software or firmware for the con- 
trol part, whichever is economical. 

3) The language should serve as a medium at all levels of 
system description. 

4) The design changes should easily be incorporated into 
the description and corresponding translation should be 
done preferably without a complete retranslation. This 
feature will be useful for an interactive environment. 

5) The language should be easy to learn and remember, to 
accommodate the software shy, hardware designer, although 
the hardware engineer can not neglect the software as- 
pects anymore , due to the impact of microprocessors . The 
design system should be portable, thus necessitating the 
the translators and simulators of HDL be written in 
higher level languages. 

6) Two approaches to systems design are often proposed: 

The bottom-up approach where the elementary components 
are combined to form more complex ones and the top-down 
approach where the system is decomposed into collection 
of sxabsystems until the elementary components are re- 
ached. In practice, the designer may choose a combina- 
tion of the two approaches. The structural detail at any 
design level varies from designer to designer. The HDL 
should allow the designer to control the amount of detail 
during each design phase. 

7) The description of the LSI and MSI modules as system com- 
ponents should be straight forward, so is the inclusion 
of newer modules. If the system is partitioned by the 
designer to accommodate standard modules, this partition- 
ing should be retained by the HDL translators and simula- 
tors . 

All the above requirements are not met by any one HDL now 

available. The solution has been to design a new HDL to suit 
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an individual design environment, AHPL, CDL, DDL and ISP have 
been the most popular languages, partly due to their early 
introduction as general purposes HDL's. These languages were 
developed in university environments and are used in teaching 
digital logic design. New features are being added to these 
languages to make them more versatile. Well tested transla- 
tors and simulators are available for these languages. A 
bibliography of the literature on HDL's is provided in [8], 

The characteristics of CDL, ISP, AHPL and DDL are sum- 
marized in Chapters 2,3,4 and 5. A comparison of these 
characteristics to select a language suitable for use in an 
automatic integrated circuit design environment is provided in 
Chapter 6 , 



2. COMPUTER DESIGN LANGUAGE (CDL) 


Computer Design Language was proposed originally by Chu 
[1-3]. A translator and simulator were written for a subset of 
this language [4] . Several modifications are made to, this 
translator and simulator [5/6] . The present version [7] is 
implemented on IBM 370/115. 

CDL describes the structural and functional parts of a 
digital system. The structural components like memory, re- 
gisters, clocks, switches, etc. are declared explicitly at the 
beginnxng of the description. The functional behavior of the 
element are described by the commonly used operators and user 
defined operators . Valid data paths are declared implicitly 
whenever there is a data transfer. Both parallel and sequent- 
ial opeations are allowed. Synchronous operations require a 
conditional test for an appropriate signal. The language is 
easy to understand and is highly readable. 

All the variables in a CDL description are global. The 
system description can be only at one level, and there is no 
S'ubroutine facility in CDL, thus making it unsuitable for 
describing hardware in a modular fashion. Gate delays and 
asynchronous operations can not be adequately described. It is 
not possible to include special hardware components like in- 
tegrated circuits in a description. However, its simplicity 
of structure and its portability resulting from the FORTRAN 
implementation, have made CDL a popular language. The 
descripton of CDL Syn- tax and Semantics as accepted by the 
present version of tran- slator and simulator is presented. 
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2.1 SYNTAX RULES 

Variables - variable names may contain 1 - 4 characters, the 
first of which must be alphabetic . The remaining characters 
may be alphabetic or numeric. Embedded blanks or special 
characters other than and " = " 

are ignored. Variable names longer than 4 characters may be 
used and will appear on the lasting, however their signific- 
ance to the Translator is limited to the leftmost 4 charac- 
ters. Some examples of variable naming follow: 

Valid: 



Name 

CDL Name 


A1BC 

A1BC 


ABbCD 

ABCD b is blank 


A1#CD 

A1CD 


START 1 

STAR 


START 2 

STAR 

Invalid : 

IB3D 

Reason 

Nonalphabetic 1st character 


AB.CD 

contains special character 

Reserved words 

- The following may not be used as variable 


names : 

IF, THEN, ELSE, DO, CALL, RETURN, and END, 

Constants - Constants may be 

entered in three forms subject 

to 

the following 

conditions : 


Form 

Max. Digits 


Binary 

32 


Hexadecimal 

8 


Decimal 

9 
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Hexadecimal constants are denoted by a colon (:) preced- 
ing the significant digits. Binary constants are proceeded by 
a semicolon ( ; ) . 

In general, for numeric constants, blanks and special 
characters other than those listed in the discussion of vari- 
able names are ignored. Characters outside the permissible 
set for the form used are also ignored. Some examples of 
numeric constants follow: 


Valid 

Value 

1234 

1234^0 

o 

o 

*♦ 

lOOFig 

7 110011 

1 1001 12 

7 1 2b 1 0 1 

1 1012 

Invalid 

Reason 

A345 

1st character not numeric 
(will be treated as variable 
name) 


2 . 2 DECLARaTION STATEMENTS 

The following devices are permitted in CDL: 

Registers Terminals 

Sub registers Lights 
Memories Bus 

Decoders Clocks 

Switches 

The syntax for a declaration statement is: 

DEVICE, list 

where the type of device begins in column two. 
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Mixed notation for devices and other keywords is shown in 
the followxng paragraphs. The first four characters are 
significant and must not contain embedded blanks or special 
characters . The following table relates keywords and accept- 
able abbreviations: 


Keyword 

Abbreviation 

REGISTER 

REGI 

SUBREGISTER 

SUBR 

MEMORY 

MEMO 

DECODER 

DECO 

SWITCH 

SWIT 

TERMINAL 

TERM 

LIGHT 

LIGH 

BUS 

BUS 

BLOCK 

BLOC 

CLOCK 

'CLOC 


Note that the comma trailing the device name is 
mandatory . 


REGISTER DECLARATION : 

REGI,A{0-2) ,R,F{6-1) ,G(0-5) 
This declares the following: 



A 


□ 


6 

A 

4 

3 

U 



R 


0 


2 

3 


5 


G 


SUBREGISTER DECLARATION ; 

SUBREGISTER, G (OP) ==G (0-2) , F (OR) =F (6-4 ) 

The subregister is always used with a register name, and 
it refers to a part of that register. All referenced regis- 
ters must have been previously declared. 
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A general tendency is to give two siibregisters the same name, 
e.g. SUBR,R{OP)=R{0-3) ,A(OP) =A (0-3) 

This is incorrect I 

A correct statement of the above would be: 
SUB,R(OPR)=R(0-3) , A (OP) ==A (0-3) 


MEMORY DECLARATION : 

MEMO, M(R)=M(0-77,0-10) , N ( J) =N (0-6 , 3-1 ) 

M and N are the names of the memories; R and J are the 
corresponding address registers which should have previously 
been declared; 0-77 and 0-6 represent the limits of the 
addresses of the words in the memories; 0-10 and 3-1 represent 
the order of the bits of each word. 


DECODER DECLARATION : 

A decoder is a logic network which translates each value 
of the contents of a register to one and only one of the out- 
puts ; 

DECO, K(0,1)=F,L(0,15)=G(2-5) 

This declares the following: 


Kr 


K, 



Lq 



P^here F and G have been previously declared. 
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CLOCK DECLARATION ; 

A clock may be specified for event synchronization, 
CLOCK, P{2) 

This declaration defines three clocks, P (0 ) ,P (1) ,P (2) . The 
impulse diagrams are assumed to be the following: 


CLOCK TIME 

P(0) 

P(1) 

P(2) 

LABEL CYCLE 



The time intervals between the impulses given by the 
clocks are the same. A clock may be referenced only in rhe 
expression of the label. 

During execution, a clock cycle is designated on the 
simulation printed results as clock time. 


SWITCH DECLARATION : 

SWITCH, STRT( OFF, ON) ,SENS (Pi ,P2,P3) 

The switch names are STRT and SEWS the positions for STRT 
are OFF and ON and for SENS they are PI, P2, and P3 where OFF 
and Pi are the respective initial positions. 

In later references a switch is either checked for one of 
its positions, or set to one of its positions. When a switch 
is checked for a position, it has the form: 

NAME(POS) e.g. SENS(P2) 
when setting a switch to a position: 
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NAME=pos e.g. SENS=P2 

NOTE: A maximiuu of 10 switch positions is permitted. 

TERMINAL DECLARATION : 

A terminal statement can rename a terminal or describe a 
logic network. 

REGISTER, A (0-2) 

TERMINAL, BO=A (0) ' ,B1=-A ( 1 ) ' , 

B2=A(2) ' 

or using siibscripted terminals 

REGISTER, A (0-2) 

TERMINAL, B (0-2) =A (0-2) • 

Both of these describe the following: 



A 

Referring to the decoder example; 

TERMINAL , ADD=L ( 0 ) , 
SUB=L ( 1 ) , 
JUM=L(2) , 
etc. 


LIGHT DECLARATION 


LIGHT, RUN(ON,OFF), FINI(OFF,ON) 

The lights RUN and FINI , each have two positions , with 
the initial position being ON for RUN and OFF for FINI. 


A reference where a light is checked for its position. 
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has the form: 

NAME (POSITION) ex: RUN (ON) 

When setting the posxtion of a light, the following 
format is used: 

NAME=POS ITION ex: RUN=OFF 

BUS DECLARATION 

BUS, INTERNAL (15-0), DATA (7-0) 

This declares INTERNAL bus with 1 6 lines and DATA bus 
with 8 lines. 

BLOCK DECLARATION : 

In order to avoid the repeated writing of a group of 
microstatements, the block statement and do statement are 
created. The block statement declares the name for a group of 
microstatements. Whenever these microstatements are declared 
in an execution statement, a do statement is used to call 
them. 

Example: Serial Complement 

REGISTER, T(1-5) ,A(5-1) 

SWITCH, START (ON) 

CLOCK, P 

BLOCK, SERCOM(A=A(1) ’-A(5-2) ) 

/START (ON) /T=20 
/T(1)*P/ DO/SERCOM,T(1 ,2)=01 
/T(2)*P/ DO/SERCOM,T(2,3)=01 

/T(3)*P/ DO/SERCOM,T(3,4)=01 

/T(4)*P/ DO/SERCOM,T(4,5)=01 

/T(5)*P/ D0/SERCOM,T(5)=0 

NOTE: DO is followed by a slash'/' and then the BLOCK name. 
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Another example of Block Declaration; 

BLOCK, PAR (A=B , R=0 ) , CYC (A=A . COUNT . , 

IF (A.EQ.1)THEN(R=1)ELSE(R=0) ) 

All of the microstatements following the block names (PAR, CYC) 
will be executed when DO/PAR or DO/CYC are called. 


2 . 3 CONTINUATIONS 


ONLY declaration statements may be continued onto other 
cards by placing a ' 1 ’ in column one of the subsequent cards . 
Label statements and switch statements may be continued on 
subsequent cards by leaving column one blank. 

Declaration and Label statements are limited to 250 
terms, where a term is considered to be: 

a device name, a variable name, a constant, or any of 

the following special characters; 

Tl I II fi^ll II *11 II I Tl fl *11 II /II If / II Tl \ IT 

f T • 

Example: 

REGI,A(0-2) , 

1 B(0-6), 

1 C(6-1) 

/K*A(2)/ B=B. COUNT. 

C=C . COUNT . 


2 . 4 COMMENT CARDS 


A comment may be made by placing a 'C in column one. The 
comment will be ignored by the translator . Comments are not 
continued in the conventional manner, rather a 'C in column 
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one of every subsequent card will continue the coimnent. 
Example: 

C SIMULATION OF A SECOND 
C GENERATION COMPUTER 


2 . 5 OPERATORS 


STANDARD OPERATORS 

The following standard operators are available in CDL; 


SYMBOL 

FUNCTION 

EXAMPLE 

EXPLANATION 

' (Apostrophe) 

Complement 

A' 


= (Equal Sign) 

Replace 

A=B 

Contents of A are 
replaced by contents 
of B . 

- (Dash) 

Concatenate 

A-B 

Contents of A & B are 
placed side by side. 

+ (Plus Sign) 

Logical OR 

A+B 

Bit-wise OR (A and B 
must be conformal) . 

* (Asterisk) 

Logical AND 

A*B 


.EQ. 


A.EQ.B 

Gives ’ 1 ’ if A and B 
are equal . 

.NE. 


A.NE.B 

Gives ' 1 ’ if A and B 
are unequal. 


SPECIAL OPERATORS 

Special operators can be established by the user through 
a separate subprogram. It is referenced by a symbolic name 
delimited by periods. 
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Example: 

*OPERATOR, X (1-4) .COUNT. 

// IF (X(4) .EQ.O)THEN(X(1-3)-1) 

ELSE (IF (X(3) .EQ.OTHEN (X(1-2)-1-0) 

ELSE (IF(X(2) .EQ.O)THEN (X(l)-I-O-O) 
ELSE (X(1) ’-0-0-0) )) ^RETURN 

END 

The first line is a heading line of the subprogram: 
*OPERATOR (or *OPER) specifies the type of the subprogram, it 
is followed by a comma and by the name of the first argument, 
the name of the operator enclosed in a pair of dots, and by 
the name of the second argument if the operator is binary. If 
the arguments represent more than one bit, the bit addresses 
must follow the argument’s name in parenthesis, e.g., S(1-4). 

The subsequent lines are headed by a blank label, i.e., 
two slashes. This indicates an immediate execution of the 
operations when the operator is called. Following the blank 
label, there must be an expression, which may be a conditional 
expression, giving the result of the output terminal. The sub- 
program must be ended with a RETURN and an END statement. 


RESTRICTIONS: 

The following special operators are built in for Simula' 
tion and they may not be defined by separate subprograms. 


A.ERA.B 

A.ADD.B 

A.SUB.B 

A. COUNT. 
A.LT.B 
A , LE . B 


performs the exclusive OR of A and B 
performs the algebraic sum of A and B, an 
overflow bit is discarded 

performs the algebraic sum of A and the com- 
plement of B, an overflow bit is discarded 
Adds one to A, an overflow bit is discarded 
gives one bit of output: 1 if the conditions 
algebraically less than, less or equal 
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A,GE.B greater or equal, greater than, are satis- 

A.GT.B fied: 0 if the conditions are not met 

2 . 6 MICRO STATEMENTS 

An UNCONDITIONAL MICROSTATEMENT consists of a variable 
representing a storage element, the REPLACE OPERATOR and an 
expression. 

Example : 

A=1 ,B(1 ,3-5) =C*D+E (2,0-2) 

NOTE: A given device or portion of a devxce must not appear 

on the left of a 'replace by* operator more than once 
in any set of microstatements to be executed during a 
given label cycle. 

A CONDITIONAL MICROSTATEMENT has the following forms: 

(a) IF (expression) THEN (microstatements) 

IF (expression) has the value ' 1 ' then the opera- 
tions indicated by the (microstatements) will be 
executed. 

Example : 

IF(A.EQ.B)THEN(R=0) 

(b) IF (expression) THEN (microstatements) ELSE (micro- 
statements) if the (expression) is true then the 
operations indicated by the (microstatements) im- 
mediately following THEN will be executed, other- 
wise the operations indicated by the (microstate- 
ments) immediately following ELSE will be executed. 

Example : 

IF (C.NE.D) THEN (R=0) ELSE (R=1 ) 
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Conditional statements may be nested in order to form a 
very powerful decision-making capability. An example of a 
nested appears in section 5.2. Note that each of the nested 
IP's must be enclosed in parentheses as shown in the following 
generalized example: 

IF (exp 1) THEN (microstatements) 

ELSE (IF (exp 2) THEN (microstatements) 

ELSE (IF (exp 3) THEN -(microstatements) 

ELSE (IF 

ELSE (microstatements) )))..) 

2 . 7 SWITCH STATEMENTS 

The Switch Statement has the following form: 

/NAME (POSITION) /microstatements 
where Name corresponds to a declared Switch Name. 

Example; 

SWITCH, STRT(OFF,ON) , SENS (SI ,S2,S3) 

/STRT(ON)/A=0,F=1 ,SENS=S2 

The indicated microstatements here would not be executed 
since STRT(ON) is FALSE. 

2.8 LABELED STATEMENTS 

The Labeled Statement has the following form: 
/LABEL/microstateraents 

where ; 

LABEL = expression * clock 
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RESTRICTION ; 

The expression must not include any clock reference. 
Example : 

/K(0)*P/ A=B, B=A 


2 . 9 END STATEMENT 


The physical end of the description of a design is in- 
dicated by the word END. 


2.10 CARD FORMAT 


HEADING CARD 

The main design and the user's defined operators must be 
preceded by heading cards as follows: 

Col. 1-5 *MAIN 
or 

Col. 1-. . ,*OPERATOR. . . 

where no embedded blanks are allowed. The Operator card 
should contain the arguments and the name of the operator. 

OTHER CARDS 

Declaration cards. Labeled Statement cards, and the End 
Card may be punched anywhere in columns 2-72. Blanks may be 
used freely. 


2.11 TRANSLATOR 


The translator accepts the logical design written in CDL 
from punched cards. It translates the design into a form 
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sui table for simulation. This consists of various tables and 
a pseudo program called Polish String. If the $TRANSLATE card 
is punched PRIN in columns 14-17, the various tables and Po- 
lish String will be printed. 

The Translator rs called by a special control card having 
$ TRANSLATE (or $TRANS) punched in col, 1-10. This card xs 
followed by the deck of cards describing the logical design 
using CDL. The Translator remains in control until a new 
control card with $ in column 1 is read in. A typical deck 
set-up should appear as follows; 

$TRANSLATE Translator is called 

*MAIN 


END 

*OPERATOR, . . . Translator is in control 


END 


$ SIMULATE 


Simulator is called 

Simulator is in control 


2.12 SIMULATOR 


The Simulator consists of 5 parts; Loader, Output, 
Switch, Simulate, and Reset routines. The Loader accepts test 
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data from punched cards and stores them into memory or into 
specified registers of the designed computer. The Output rou- 
tine handles the printout of the contents of the chosen regis- 
ters, memory words and position of switches during the simula- 
tion. The Switch routine simulates the operation of the 
manual switches. The Simulate routine actually executes the 
test program. Reset routine reinitializes the Simulator. 

The execution of the test program is controlled by a loop 
which is called the Label Cycle. During each label cycle, the 
following steps are taken; (a) If a manual switch opera- tion 
occurs, the corresponding executable statement for the switch 
operation is carried out. (b) All label values are evalu- 
ated. The activated label, i.e., the label expressions having 
the value TRUE, are accounted for. (c) The microstatements of 
the activated labels are carried out in two steps. First, all 
values to be stored in various registers and memory words are 
evaluated and collected. Then, the collected values are 
stored one after the other. (d) It is checked whether the 
simulation should be terminated. 

If the Simulation is terminated, the Reset routine can be 
called and another set of data can be inserted as a test 
program. 

Example; The following is a demonstration of a simula- 
tion with 2 test programs - 
$ TRANSLATE 
*MAIN 


END 

*OPERATOR, 


CDL Design cards 


END 

$SIMULATE 

*OUTPUT 
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*SWITCH 

*LOAD 


*SIM. . . 

*RESET 

*LOAD 


*SIM. . . 


LOAD ROUTINE 

The Loader provides the storing of test programs. The 
data cards should use Col. 2 - 12 , blanks may be inserted 
anywhere. Only declared full registers and memory words with 
constant addresses can be loaded with data. The format of the 
data cards is as follows: 

Data loaded into a register: REG = d 

Data loaded into memory words M(L)=d 

or M(L^-L^)=d^ ,d 2 , ,d^ 

or M(L^-) =d^ ,d 2 , . . . ,d^ 

Where REG is the name of the register whose contents must be 
set to the value d. M is the name of the memory and L^ de- 
notes word addresses. In the first case d is loaded into 
memory word M{L) . In the second case, the words ate 

loaded into memory words with addresses L^ to L^ consecutive- 
ly. In the last case, the last address is defined by the 
number of numbers punched. 

A data card may contain any number of lists separated by 
commas. There is no provision for a continuation card, thus 
each data card must start with the name of a register or a 
memory in column 2. 

Example: 

*LOAD 

R1=0,AC=20,SEP=72,M(0-3)=1 , 2 , 3 , 4 ,M (77) =345 
M(IO-) =70, 71 ,72,73,74,75,76,77,100 
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OUTPUT ROUTINE 

The output routine provides the printed output of the 
contents of specified registers, memory words and positions of 
switches during the simulation. The following format is 
required: 


Col. 1-7 

* OUTPUT 


LABEL 

Col. 11-15 

or 


CLOCK 

Col. 16-21 

(n,m) = 

Col. 22-72 

list 


Where the label or clock punch specifies the type of output 
required, n specifies the start of output and m specifies the 
frequency of the output. The list consists of the names of 
the registers, switches and memory words whose contents should 
be printed. 

During the simulation, the output may occur at every mth 
label cycle or at every mth clocktime depending on the type. 
Label or Clock in Col. 11-15. If the design happens to have 
one clock, then the two types coincide. 

Example : 

*OUTPUT CLOCK ( 1 , 10) =RR, START, M(0) ,M(777) , 

AC,MQ,M(10) ,OVER 

The list may be continued on the next card(s) provided that 
column 1 is lefr blank on the continuation cards. The output 
of all listed devices is given in hexadecimal, regardless of 
input format . 


SWITCH ROUTINE 

Manual switch settings are initiated by the Switch rou- 
tine. The necessary information is given on *SWITCH cards. 

For each switch setting, a separate *SWITCH card is necessary. 
It has the following format: 
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Col. 1-7 *SWITCH 

Col. 11-12 L, 

Col. 13- NAME=POSITION 

Where L specifies the Lth label cycle before which the switch 

operation occurs . The NAME corresponds to the name of the 
switch with POSITION as one of its positions declared. During 
the simulation, an output will occur after every switch 
setting with a heading stating the interrupt. 


SIMULATE ROUTINE 

The actual simulation starts by calling the Simulate 
routine using the control card with the following format; 

Col. 1-4 *SIM 

Col. 11- n,r 

Where n and r are the terminating conditions , n is the maximum 
number of label cycles allowed, r is the allowed maximum 
number of consecutive label cycles such that the same group of 
labels is activated in the CDL program. 

Example; 

*SIM 400,3 

RESET ROUTINE 

The Reset routine reinitializes the Simulator to its 
initial conditions . It is called by a control card with the 
following format: 

Col. 1-6 *RESET 

Col. 11- (options) 

The options may be one or more of the following terms 
separated by commas ; 

OUTPUT, resets the output requested previously, it 

is assumed that another *OUTPUT card will be 
given 

SWITCH, resets the manual switch operations re- 
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quested it is assumed that another *SWITCH 
card will be given 

CLOCK, resets the counter of the clock cycle 
CYCLE, resets the label cycle counter and the clock 
cycle counter 

Example: 

*RESET CYCLE , OUTPUT 


The reset card then followed by other OUTPUT card, pos- 
sibly other LOAD card with data, and by a SIM card. 

CDL translator and simulator also have an extensive error 
diagnostics capability. 


2.13 DESIGN EXAMPLES 


The design process using CDL for a serial two’s comple- 
menter circuit is illustrated [8] in Figure 2-1 . A similar 
design example is provided in [9] . Several CDL descriptions 
can be found in [10], 

Figure 2-2 shows a sequential circuit along with the CDL 
description and simulation results, 

A CDL description of a variable timer circuit shown in 
Figure 2-3 is provided in Figure 2-4. CDL is highly suitable 
for this level of description. 

Basically, the circuit consists of a devide by 3600 
circuit R along with a counter CT that counts the number of 
times R goes to zero. CT is compared with the input setting 
IN. IF IN equals CT an output pulse is given and the START 
flip-flop is reset to disable the clock. ABORT input clears 
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Qgjooa 


REGISTER, R (l~6) 
REGISTER, C (2-0) 

REGISTER, S 

L LIGHT, L (on, off) 

SWITCH, SW (on, off] 
(B) 

C-A] storage structure 
(b) CDL description 

Figure 2-1 Serial Tv;os Complementer 













REGISTER, T (1-3) 


1 2 


clock 


r 

I 



CLOCK, P 


(D) 

. SW (on) 



Figure 2-1 (d) Control elements 

(e) State diagram 

(f) col description of control 
sequence 


mm. 


©TSE PAGE' IS 
t©OR QUAUTY 


END 


(e) 


/SW (ON ) / 
/T(1)*P / 
/T(2)*P / 

/T(3)*P,/ 


T IOO 2 
T ^ OIO 2 

IF (C=6) THEN (T^00l2) ELSE (T^1002) 


T 000 

2 

(f) 



STKA.'-iSLATe 



C STORAGE 

“RFGISTERTR Tl-olTC R-(TJT 
LIGHT, L{0‘'J, OFF) 


C CONTROL 

—REG I ST ER7'TTL--^3 r 

CLOCK, P 

'C PROCtS^R 

/SW[ON)/T=;iO0,C=O, L=0FF,S=0 
— 7nrT^r^/T--TOTTrTr=7!rTCOTTwT-TTT~F^ G ) rTTcTrt-S^-rrt- 

ELSE(R=(R{6) '-RIl-S))) 

— / TTZr]^Prirf-[ CTEg-i-rri-O }-T1Hf:-ftt7r”0D D'E t-S£'(T^m.T?T)- 
/T ( 3J*P/r= ;000, L=ON 

--£?^0 


rr)' 


SSIMULATE 

-^aOTi>U-T ei-OC-K-Ll-TlF) =R rerS-TT-Ttr 

WITCH l,SW=ON 

-^LOAO 

R=S 
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ORiCiNAI, PAGE IS 

nurpvu nt si’iuLAri.iN 


SWITCH INTERRUPT »rfr 

SW = ON - 

R = ..05 C = ...0 S = ...0 r = ...4 L = OFJ- 

7 «•*#<!<=*** <> 

L4HEL CYCLE I TRUE LABELS CLUCK CYCLE 1 

/TlDtp/ 

R = ;.2Z - c = ,;.i - S' = ...L — -T-= ;.;2 L = uef “ 

i: * ir 4: + # C »<;<: * <:j{; * 7 <• # ? < ** ^ <1 4 * 4=# ^ *4- -44: 

LABEL CYCLE 2 TRUE LABELS CLOCK CYCLE 2 

/T(2)*P/ 

R = ..22 C = ...1 S = ...I T = ...4 L = Off 

454:4!74;4;4:74!*4[4!4: 7* ^ ^ 4t;|t4! 7 # 4-^ \»«4;4i<;*4-4:4-4- <=4-4:4- 4: *:74-4-4:4;4- 4 <-* f 4 4:4- 

LABEL CYCLE -3 TRUE LABELS — -- - - - CLOCK CYCLE - 3 

/I I 1)«P/ 

R = ..31 C = ...2 S •= ...I r = ...2 L = OFF 

4= 4 4 C-* 4- 4; 4- 1! <- 4= <I 4= 4 4 <: 4-44:4: 4 4= <: 7 <: 4- *:*<:<:<• 4=4:4- 74' <= 4- 7<- <:*<:* <=<=<: 4- 4- 4- 4-4= 4 *<=<:<■<■<-<• 4= <- 1 <• 7<-4- -4= 4= 4-7 

LABEL CYCLE 4 TRUE LABELS CLOCK CYCLE <4 

/rt2)«P/ 

ft = ,.31- -- C - ..;2 S = .-,1 T-=-.-.^A L-= OFF 

LABEL CYCLE 5 TRUE LABELS CL(!CK CYCLE 5 

/TI l)4=P/ 

R=..19 C= 3 S = 1 -r= 2 L^UfF 

44=47 4=e4i47 7*4:*4:77 7774=4:7774:4=777 4i7 7r7774=7 774.77 77 74!4!447444-4t<-4-774 7777 74=4--7774-4-4 7 

LABEL CYCLE - 6 TRUE LABELS" CLOCK- CYCLf 6 - 

/T(214=P/ - 

R = ..18 C = ...3 S = ...1 T = ...4 L = OFF 

4=4 47 74-7 47 74444 77:774:4:74:4747744' 4=7 777447777 4777 v 77777 7=-= 74 777 4" 77 < 4 4 7 7 74 ^7 7 4 V-, - 7 
lABEL CYCLE 7 TRUE LABELS CIUCK CYCLF 7 

/T I IJ7P/ 

- R =-..2C- -C--=--..-.=^ S =— ;.l--' --J = ,-..2-"- L'= OFF 

7771.V777 77777777 7777777777777777 7777777 77777 7777777 77 7477- 7 .77 77 77 777<47-=-4474 
LABEL CYCLE 8 TRUE LABELS CLOCK CYCLE 8 

/T(21*P/ 

R = ,.2C - C = ...A S = ...1 T = 4 L = OFF 

7477777777777777777777777777777777777777777777777777777777777777777777777774 

LABEL CYCLE 9— TRUE-LABLLS ' CLOCK CYCLE V 

/Tm7p/ 

H = ..36 C = ...5 S = ...I T 7 ...2 L = OFF 

7 777 7-4 77777 7 4 77777 7777777777 7-- 77*7777 7 7 47777 7 77 77 74 77777777*7777 4 7 4 77. ..7 •‘-7 4 

LABEL CYCLE 10 TRUE LABELS ’ CLUCK CYCLE 10 

/T (2)4=p/ 

R=-..36-- -C=-.-: .5 S -- . . . I T - ^ . rA — - L - ore - 

7747777777777777777777777777777777747777777777< 777 74-777-4774 777777-4 777747774 

LABEL CYCLE 11 TRUE LABELS CLOCK CYCLE ll 

/T[1)7P/ 

R=..3B C =...6 S=,..l r=...2 L= UFF 

4 7 47 77 7 74 4 47 4*77 7777774 7 *77 7777 77 77*77 77*7 7 7 7 777777 7777777 777 77 7-74 777 7 77 4 74 

LABEL CYCLE ' '12 * — 'TRUE LABELS — CLOCK CYCLE 12 

/ri2)7P/ 

R = ..3B C = ...6 S = ...1 r = ...1 L = UfF 

4 7*7*77 77*777777 77777 77 7*7*77 77 77 7 7-777 777777 7*7 7777 777777 v 74 74 74 7*777747*7 
LABEL CYCLE 13 TRUE LABELS CLOCK CYCLE 13 

/T13)7P/ 

R-=..3I1 C = ...6 S-=...l - T-...0 L = f,M 

* *7**777*7777*774*477777**777*— 777777-C7* — 7777777*7*7**7777**7774 7*74 777*' 

A7«7 SI'IULATION IFR'IINATEO - NU TRUE LABELS 
7RESET CYCLC, CLUCK 
7L0AD 
R = 21 

A r T *« * ^ t , I- U-.. 1 


10 


Figure 2-1 (H) 


Simulation Results for R=5 






mr 
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I I I ORIQlNAi; PAGE IS 

= (X^ . S) . X^ . X^ . Xg 

M4 = (M^ . S + X2) . (X^ + M^) . (X^ + x'^) 

Mg = X^ + (X^ . Xg . Xg . M^) 

Figure 2-2 (B) : Boolean Equations for the Circuit 
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STRANSLATE 

#MAIN 

SWITCH, STARTION] 

REGI, FFU-6), M2tM4,M5, X 1 1-6 ) , ST ( 0-1 J 

CLOC, P 

TERM, T1-M2+M4,M3=1X( LJ^X(6J ) **FF { I )*FFt2) '=i=FF{4) , 

1 T3=^M2^^M3, T4= M2-^M3^■M4 

/STARTfQN)/ST=l 

/P»ST( U/FF-X,ST=2 

/P*ST( 0) /M2={FF(2) +FF[6J )^FF{ 1)*{X{1J*X(6)]', 

M4^ IM5*X(6) + IFFU) j » ) * ( FF ( 3 ) +FF { 5 ) ) * 

IFF! 2J+FF {4) 3 , 

M5=Xa) + (FF( 1J^(FF(2) ) * ^‘ ( FF ( 4 3 ) • « ( F F [ 6 ) 3 • 3 , 
ST=1 

EN D 

$SIMULATE 

^OUTPUT CL0CKtl»l)=FF,H2TM4,M5>X,STT5TART 

^SWITCH 1,START=0N 

»LOAO 

M2=1,M4=1,M5=1 

»SIM 25,2 

END OF DATA ON INPUT 


NOTES; S is renamed as X(6) in tJie above description. 

Modules 1-6 of the circuit, are named FF (1-6) . 


Figure 2-2 (6) ; CDL description of Sequential Circuit 
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OUTPUT OF SIHULATION 




-JS'- 


SKITCH INTERROPT 

STAR - ON __ _ 

FF = ZTOO '"ft? = -.'.1 R4 = K5 * ../l ■* X = ..00 ST“= ^.'.1 "SFArl = 


•♦»**•♦***♦♦♦»*♦»••**♦»•♦•»«»♦»**»♦»***»•»•***»»*«»»*«*»»»»»* *»♦•*«»»*•»»*»»*«♦*»»«♦ **ar»«*-*-¥^ccre 

tAB£L“CfCLe I “ TRU6“LASE1.S cldck' cycl 1“' “l 

/p»sTm/ 


FF = *.00 

HZ = ...1 

II 

• 

• 

*-« 

“5 = 

...i 

X 

= ..00 

ST = ...2 STA- ^ 


LABEL CYCLE 

2 

TRUE LABELS 
/P*STt01/ 



CLOCK 

cycle 

2 

FF = ..00 

«2 = ...0 

H4 » ...0 

H5 = 

...0 

A 

= ..ou 

ST = ... 1 ST A- = w . 

*K*44 4 *»*««««*** 4* »«S* *4 4 a* :*«««*«*««« «»»««« S««**iOc»*«4««;««^4««vvx;«*W 0 7 

label cycle 

3 

true labels 

/P»STC1J/ 



CLOCK 

CYCLE 

3 

FF • ..00 

M2 « ...0 

H4 > ...0 

H5 

...0 

X 

= ..00 

ST = ...2 STAR = u^ 

4*«****««*4»*«*»*A»**a«»»««tt*«*********44 44*»A****A«*«^«**«*«tt*tt^V*««K*4«*«»«*0»*ttX*74:«**9«ea!tt«** 

LABEL cycle 

4 

TRUE LABELS 
/P*STtO)/ 



CLOCK 

CYCLE 

4 

FF =* •.OO M2 * ..,0 

* ...0 

• « !«t ** « *4r«« «« 4c 4c 

MS - 

^4c49V4c: 

... 0 

X 

999999H 

= ,.00 

ST == ...1 STAR = ON 

LABEL CYCLE 

5 

TRUE LABELS 
/P»STtl) / 



CLOCK 

CYCLE 

s 

FF » —00 

M2 ° ...0 

M4 « ...0 

«5 = 

...0 

X 

= ..00 

ST » ...2 STAR = ON 


^JJIBEL CYCLE 

6 . 

TRUE LABELS 



CLOCK 

cycle 

6 

- -*•= 

. V‘ 

/P*STIO)/ 






FF = ..00 

«Z = .,.0 

H% = ..,□ 

M5 = 

...0 

X 

= ..00 

ST = ...1 STAR = ON 




^LABEL CYCLE.-. 

^7 


■raUE-LABEUS 
/p«rci)/ ~ ' 

- 

XLQCK 

CYCLE . 

7 

-- 



FF - ..00 


H2 >= ...0 

M4 - «..0 

MS = 

...0 X 

« ..00 


ST = 

...2 STAR c ON 

LABEL CYCLE 

8 


TRUE LABELS 
/P*ST(0)/ 


CLOCK 

cycle 

a 




FF « —00 


M2 = ...3 

MA- = 0 

MS = 

...0 X 

= —00 


ST « 

1 

STAR =r aN 




LABEL CYCLE 

9 

TRUE LABELS 
/P*STC1J/ 

CLOCK CYCLE 

9 


FF *= ..00 

HZ ^ 0 

H4 = —.0 

MS = —.0 X = ,,00 

ST = ...2 

STAR ■= ON 




LABEL CYCLE 

10 

TRUE LABELS 
/P*STtO)/ 

CLOCK cycle 10 


FF - ..00 

M2 = ...0 

M4 = ...0 

M5 = .,.0 X = ..00 ST * ...1 

STAR « ON 




LABEL CYCLE J.I 

TRUE LABELS 

CLOCK cycle 

11 


/P*STI11/ - 




j — FF^»^*00 .. «2 « «««0 «4 *^♦♦•0 - HS » ^..0 X = •.00 ST « ...2 STAR = ON 

" *»**»»* ******»*#»»»**»»»»»»»♦ 


LABEL CYCLE 12 



TRUE LABELS 
/P*ST10)/ 


CLOCK CYCLE 

12 





FF = —00 

M2 » 

...0 

H4 = ...0 MS 

a ...0 

X » —00 


ST 

S 

...1 

STAR * UN 


LABEL CYCLE - 13- 

- 


TRUE LABELS 


CLOCK CYCLE 

13 






— 

- 

/P*STJ1)/ 








FF = —00 

M2 => 

...0 

H4 - ...0 MS 

a .*.0 

X = ..00 


ST 

s 

— .2 

STAR = ON 


LABEL CYCLE 14 



TRUE LABELS 
/P*ST(0)/ 


CLOCK cycle 

14 





FF a *.00 

M2 = 

...0 

M4 * ...0 M5 

— • * * 0 

X * ..00 


ST 

= 

...X 

STAR = ON 


LABEL CYCLE 15 



TRUE LABELS 
/P»STI11/ 


CLOCK CYCLE 

15 





FF - —00 ' 

M2 - 

—.0 

M4 « , — 0 — — MS 

■ ...0 

X s ..00 


ST 

s 

. — 2 

STAR = ON 


LABEL CYCLE 16 

, 


- TRUE LABELS ". ■ — 

. — — — 

CLOCK CYCLE 

- 16 


. 






"/P*STiOJ/-- “ ' ■=”' 

’ ■" 


~ 





-FF..«-.-.00- - -- 

-M2 - 

rt . 

- _' N4-T«=-,— 0. - - MS 

«=...o 

- - X • —00 


ST 

m 

.—1 

STAR = ON 




LABEL CYCLE 17 ' 

TRUE LABELS 
/P*STC11/ 

CLOCK 

CYCLE 

17 



FF - —00, M2 - - — 0 

M4 « ...Q 

MS a ...0 X 

a «.00 


ST a ...2 

STAR a ON 


LABEL CYCLE -IB _ . , 

TRUE LABELS 
/PFSTIOJ/.,^ — 

CLOCK 

CYCLE ^ 

IS 



FF '•*”'^.00 _ir.~’“'"M2 * wia.O. 

^3^**^*** *********** **♦**♦♦♦** 

hM 4 «-...CX— 
c***********««»4nnh 

MS 0 X 

»**»*»*»»»*»»>*»♦« 

« ..OQat 


ST a *..l 

» « « * *1 

star • ON 


Figure 2-2 (D) : Simulation results for the Sequential Circuit 
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"label cycle "20 fRUTlABELS"" CLOCK CYCLE 2u " ~ 

ifp*sri oi/ _ 

FF = -.00 M2 ” ...0 H4“«‘..,0 " ‘C? "= ...0 " X =' .V 60 ' jT = V.'. 1 ~ STAi-' = 01* 

9 ««9T ««%««««« ««4c &****«««»«- «c«s»»ftxr%«(«^«*S:e;sV««*««3««« 

LABEL CYCLE "Zl ““ TR"UE~ LABELS” ’ CLOCK CYCLT " 2l" 

_ , .. /P*ST(ll/ _ 

Ff - -.00 M2 » ..'.o' ■ " H4 = ...0 ” '►‘S ...0 X = ..jj ST » ,..f TTAR * fH, 

*»****»»»*»*********#****’^**«*»*»»«B*»¥»B***BBBfB»»«B»»B«**»»*»*»^0«B**<>*#llt***Ttt»*<t<l*»**=Ss**B#» 

"label cycle" 22 ^ru£*'labels ' clock cycle 22 

/P»ST(0 )/ _ 

FF = ..00 KZ~» ...O MA = ...0 MS - ...'o "x’s" ..CJ ST =”...1 STAR = ON 

4< **•*******«*«««*«••*«**«****** A**S ««**«**♦ S Y V « « ^ A » **«*^« V * C* ft YBI 

label cycle 23" ' “ 'true LABELS ' CLOCK. CYCl^ 23 

_ /^STLII/ 

FF ft ..00 H2 ft .."".O " M4 ft ,..'o Ms = ...0 X = ..00 ST = ...2 STAR = ON 

ftftftftftftftftftftftAftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftftft ftftftftftftftSB BftftftftftftftftftBttXkttftftftftftftftftBBB 

"label cycle "2? TRUE LAB eCs ' CLOCK CYCtE" 2A ' ”” 

/P*ST1QI/ 

F'F = i.QO M2 ft ...0 M4 ft ...0 M5'= ..TO "'x = .,03 ST = ..."l" STAR = ON 

*•******«***«««#»»«****««*«•*«« »«*«««»*« ***««««««« r «»«««««»»♦ 

LAB"eL CY'CLE 25 TRUE LABELS ' ^CTqCK CYCl’E 25 

/P»STtH/ 

FF ft .,00 M2 ft ...O MA ft ...0 M5 = ...0 X = ..00 5T ft ...2 STAR = ON 

»m»*^*»*mm»x*m»»*»****»*»x**9***»*******»*i‘**»*******-^*9**a*9m*»»***»»****v»**’tr»»******-»mt‘**.*rt 


••*• SIMULATION TERMINATED AFTER REOUESTED LABEL CYCLES 


Figure 2-2 (D) ; 


(continued) Simulation results for the 
Sequential Circuit 
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Figure 2-3: Variable Timer 
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S TRANSLATE 
*MAIN 

REGI, R(12-1), CT(1-6), IN(1-6), START 
CLOCK, P 

SWITCH, ABORT (ON, OFF) 

LIGHT, OUT (ON, OFF) 

/ABORT (ON)*P/ R=3575, CT=0 , START=1, OUT=OFF, 
ABORT=OFF 

/START*P/ R=R. COUNT., IF ( (R ( 5 ) *R (1 0 ) *R (1 1 ) *R ( 1 2) ) . 
EQ.1) THEN (R=3575, CT =CT, COUNT.), 

IF (CT.EQ.IN) THEN (OUT=ON, START=0) 

END 

$ SIMULATE 

*OUTPUT CLOCK (1,1)=R, IN, ABORT, OUT, START 
* SWITCH 1 , ABORT=ON 
*SWITCH 2 , START=ON 
*LOAD 

IN=5 

*SIM 3600,600 


Figure 2-4: CDL description of the Variable Timer 
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R, CT and START. START input sets START. In the CDL des- 
cription, R is counted up from 3575 rather than zero, to save 
some simulation steps. 

Each cell of R (or CT) consists of an 1-0 edge-triggered 
f flop F, a multiplexor M and a Nand-gate and the ith cell 
(i=1,12) is shown in Figure 2-5. 

There is no direct way of describing the internal opera- 
tion of this ripple counter in CDL. A description for a three 
stage counter is shown in Figure 2-6. 

This description implies a parallel operation, according 
to CDL convention, rather than the ripple action of the 
counter . 


2.14 EXTENSIONS 


Some extensions to the language are reported. Bara and 
Born C6] report a version of CDL with the following addi- 
tions : 

ARRAY REGISTER 

ARRAY REGISTER, AR (0-2, 1-4) 

implies 1234 


0 


1 


2 
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MULTIPLEXQR (DATA SELECTOR) 

EX: REGISTER, SELECT (0-1) 

DATA SELECTOR, DTA(SELECT)= DTA (T0-T3) 
implies 


Terminals 


Declared 


Previously 


0 1 



PARTITION 

Devides a bus into partitions , 
BUS, DATA (0-7) 

PARTITION, DATA (OP) = DATA (0-2) 
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STACK MEMORY 

STACK MEMORY, Name (level. Mar) = Name (size, word 

length) 

STACK MEMROY, STK (3, MAR) = STK (0-3, 0-2) 

Implies 



lOFLAG 

IOFLAG,R declares a 1 bit flag R. It can be set (=1) 
or reset (=0) . When set, the OUTPUT is enabled for the label 
cycle; when reset, the OUTPUT is disabled. 

Following are some features of purdue extended CDL [5] 
simulator: 

SET (M,7) places a 1 in a single bit register M 
at the current time plus 7 cycles. 

CLEAR (M,7) opposite to SET. 

COMP (M,7) complement M after 7 cycles. 

EXIT is used to terminate simulation from 

design specifications. 

/ERROR*P/RUN<0 ,EXIT 
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Both the extensions have a complete set of operators to 
include decrement, circular shifts, shifts, ADD, SUB, MPY and 
DIV, 



3. INSTRUCTION SET PROCESSOR (ISP) 


The ISP notation was first introduced by Bell and Newell 
[11] as a formalism to describe digital systems at the pro- 
gramming level. The original notation was used mainly for 
publication purposes. A subset of the notation, ISPL [12] was 
implemented and was used in the design automation and archi- 
tecture evaluation applications [13]. The present version ISPS 
is an extension of ISPL and is implemented on PDF- 10 compu- 
ters. A translator [14] and a simulator [15] are available, 

ISP was designed to provide a precise description of 
computer systems as seen by the programmer. The description 
consists of four main parts: a declarative section, an in- 

terpreter, an instruction set description and an effective 
address calculation. The structural components are described 
in the declarative section. The effect of each instruction on 
the processor, registers, control flip-flops and memory forms 
the instruction set description. The interpreter section de- 
scribes the fetch and execute cycles. The effective address 
part describes the processing of the address part of an in- 
struction. 

The language is suitable for the behavioral description 
at high levels, where timing information is absent. It allows 
parallel and sequential operations . Modular descriptions are 
possible at higher levels. The lower level description of the 
system is difficult because of the inability to describe de- 
tails. The Syntax and Semantics of ISPS are described below. 


- 42 - 
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3 . 1 SYNTAX RULES 


VARIABLES (IDENTIFIERS) 

Identifiers must start with a letter, can contain A-Z, 
0-9 and and can be upto 80 characters long. 


CONSTANTS 

The following examples illustrate the formats allowed; 


NOTATION 

BASE 

LENGTH (bits) 


4095 

10 

13 

one bit longer 
than needed 

"1000 

16 

16 


#1000 

8 

12 


* 1000 

2 

4 


M10? 

2 

4 

? is don't care 

12? 

10 

UNKNOWN 



COMMENTS 

A comment is indicated by a ' ! ’ . Everything from ' 1 ' to 
the end of the line in which it appears is- treated as a 
comment . 


ALIAS 

Alias is an alternate name given to an identifier or a 
constant. It follows a "\" in an identifier declaration. It 
is a comment, not a usable name in the description, 
ex; IR\ INSTRUCTION REGISTER 
'OIIOVMASK 

#204\AND INSTRUCTION 
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MAME-PAIRS (RANGES) 

A name-pair is an abbreviated notation for a list of 
consecutive constants. 

ex: 3:5 is equivalent to 3,4,5 

7:2 is equivalent to 7, 6, 5, 4, 3,2 
4,5: 7, 8 is same as 4, 5, 6, 7, 8 


3 . 2 OPERATORS 


The following is the list of operators in increasing 
order of precedence: 


transfer-op 

: : = 

1 = 

1 <= 




or-op 

: : = 

orI xor 




and- op 

: : = 

AND ( 

EQV 




relational-op 

: : = 

EQL 1 

NEQ 

I LSS ! 

LEO 

1 GTR 



geq I 

TST 




add-op 

; : = 

+ 1 = 





mult- op 

; : = 

* 1 / 

1 MOD 




shift-op 


SLO 1 

SL1 

1 SLR 1 

SLD 

1 SRO 



SRR ( 

SRD 




concat-op 

• * 
* « 






unary-op 

* • “ 
• * 

NOT 1 

+ I 

- 



are equivalent 

and 

perform a 

logical 

transfer. 


SRI 


<= performs an arithmetic transfer., 
explanatory . 


Other operators are self- 


3 . 3 ARITHfffiTIC REPRESENTATIONS 


Four standard arithmetic representations are available: 
Twos - complement. Ones - complement. Signed - Magnitude, 
Unsigned - Magnitude. The selection of the representation in 
the context of an operation is indicated by, 



-45- 


{tc}, {OC},, {SM} or {US}, 
ex; Y •^Y+{TC} 2 Twos complement addition. 

3.4 DESCRIPTIONS 

ISPS defines the structure and behavior of the components 
that make up a digital system. The structure of the components 
is defined in terms of the carriers used to transfer and store 
information. The behavior of the components is defined in 
terms of the sequence of operations that transform values con- 
taned in the carriers and produce new values. 

ISPS-declaration : ;= e-declaration 
e-declaration e-head ( 

e-head := e-body | 
ISPS-definition 

An ISPS-declaration is the minimal parsing unit. An 
entity declaration (e-declaration) defines a hardware com- 
ponent which might have a structure and exhibit some behavior. 
The entity head defines the structural properties. The entity 
body, if present, defines the behavioral properties. 
ISPS-definitions are described in 3.7. 

ISPS ENTITIES — STRUCTURE 

The structural part of an ISPS entity is defined by the 
entity head (e-head) ; 

e-head ::= identifier fc-set fs-set 

■ fc-set : := nil I 

0 I 

(e-head-LIST* ) 
fs-set : : = nil f 

bit-fs-set J 
word-fs-set bit-fs-set 
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word-fs-set ;;= [name-pair] 
bit-fs-set ::= <> 1 

<name-pair> 

The identifier distinguishes the entity from other entities 
defined at the same level or scope. 


FORMAL STRUCTURE SETS 

The formal structure set (fs-set) defines a carrier. The 
carrier may consist of a single register or an array of regis- 
ters (a memory) . Syntactically, there is no difference be- 
tween the structure of a storage carrier (e.g. a register) and 
the structure of a non-storage carrier (e.g. a bus) . A multi- 
register carrier specifies the dimensions of the array inside 
'[' and ']' (the *[’ and brackets indicate the presence of 
an addressing mechanism whose implemtnation is not specified) . 
The dimensions of each register are specified inside '<* and 
The elements of the name-pairs (the dimensions) specify 
a naming convention for the 'words' and 'bits' of a carrier. 

An empty bit-fs-set (<>) stands for a single, unnamed bit. 

Examples 

Ir\ Instruction Register<0 : 3 1> 

Mp[0:255]<7:0> 

The first example above, defines a 'register' (IR) whose 
structure consists of 32 bits (0,1, ...30, 31). The elements of 
the name-pair 0:31 specify the name of the bits. The second 
example shows the declaration of a 'memory' (Mp) whose struc- 
ture consists of 256 words, each 8 bits long. The words are 
named 0,1, 2,.. 255 while the bits inside each word are named 
7, 6,. ..,1,0. 

The examples show that the bit and word names can be ' 
specified in ascending or descending order. In fact, the 
name-pairs do not even have to begin or end on 0 , as the 
following example shows: 
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vma\ Virtual . Memory. Address <13:35> 

The VMA register is declared to be 23 bits long, the bits 
named as 1 3 , 1 4 , . . . , 34 , 35 . 


FORMAL CONNECTIOlSr SETS 

The formal connection set (fc-set) defines an interface 
for connecting entitles. In ISPS, the default implementation 
of a fc-set is by means of storage units which are loaded when 
the entity is activated. This default can be overruled and 
the interface implemented as a non-storage unit: 

Examples : 

ALU (Areg<0 ; 1 5> , Breg<0 : 1 5>) <0 ; 1 6> 

P(REGI0;7]<0:7> {REF}) 

The first example defines the structure of a 'functional unit’ 
(ALU) which consists of two interface registers (AREG<0:15> 
and BREG<0:15>). By default, any activation of ALU implies 
the storing of some values into the interface registers. After 
this initialization takes place, the interface registers can 
be read or written inside the body of ALU without affecting 
the registers from which the initial values came. This is the 
default mechanism for "parameter" passing in ISPS. 

The second example presents a different type of "para- 
meter" . Its interface (REG [0 ; 7] <0 : 7>) has been tagged with the 
string " [REF] " to indicate that the interface is not a storage 
unit, local to F, but that it is a REFerence to some external 
entity to be specified at the activation site. When F is 
activated, no transfer of data takes place. REG is simply 
"connected" to whatever entity was specified at the call site. 
This connection remains in effect throughout the length of the 
activation. 
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ISPS ENTITIES — BEHAVIOR 

e-body : := BEGIN secfcion-LIST END I 

BEGIN b~ express ion END I 
e-head-LIST@ 

section : := section-header e-declaration-LIST 

SECTION=HEADER : ** identifier ** 

An entity body (e-body) defines the behavior of an 
entity. The most general case of an e-body consists of a list 
of sections (section-LIST ) , each consisting of a sectxon- 
header followed by a list of declarations (e-declaratxon-LIST) 
local to the body. This type of body is bracketed by BEGIN/ 
END pairs which can be substituted by pairs. However, 

BEGIN can not be matched by ’ ) ’ and ' ( ' can not be matched by 
END. 

Example: 

Mini ; = 

BEGIN 

**Mp\ State** 

MP \Primary. Memory [255:0] <1 1 :0>, 

**Pc. State** 

PC\ Program, Counter<7 ; 0>, 

L\Lxnk<7 ;0>, 

ACC\Accumulator<1 1 ;0>, 

* *External . S ta te* * 

10 . Reg<7 : 0>, 

Run<0>, 

* * Ins true tion , Format* * 

IR\Instructx on. Regis ter<1 1 :0>, 

**Address .Calculation** 

Z\Address .Register<7 : 0>:=BEGIN END, 

**Instruction .Execution* * 

Fetch := BEGIN END, 

Execute ;= BEGIN END, 

**Instruction . Cycle** 

Icycle := BEGIN END, 

END 
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The example depicts the body of the declaration of an 
entity, in this case a minicomputer. The declarations xnside 
the sections can be as large or complicated as one wishes to 
make them. They can, in fact, have bodies with local sections 
to any level of nesting. 

Declarations are grouped in sections as an abstraction 
mechanism. Application programs which manipulate ISPS 
parse trees will require specific sections to be present 
while possibly ignoring others. 

Simpler bodies are defined by a b-expressxon (a behav- 
ioral expression) which can be thought of as a sequential or 
combinational network depending on the nature of the opera- 
tions used and the implementation thereof. As in the previous 
case, the BEGIN/EKD bracketing the body can be substituted by 
. 

Example : 

Z\Address.Register<7;0> := 

BEGIN 

DECODE I. Bit => !test the indirect bit 

BEGIN 

Z«-Adr, I I. Bit = 0 

Z«-Mp [Adr] <7: 0> ! I. Bit = 1 

END 

END 


Notice the use of the carrier associated with Z (Z<7:0>) 
in the computatxon of the effective address. Algol-like scope 
rules are used in ISPS and non-local carriers can be accessed 
from inside a body (e.g. I. Bit, Addr, and Np) . 

The third type of e-body is defined as the concatenation 
of one or more carrxers using the @ operator. This is useful 
when defining alternatxve structures and naming conventions 
over previously declared carriers. 
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Examples 

IR\Instruction. Regis ter<1 5 : 0>, 

OP\OP,Code<2:0> ;=IR<15:13>, 

I.Bit\lndirect<> ;=IR<12>, 

Adr<11:0> :=IR<11:0>, 

I0.Bits<4:0> :=IR<12:8>, 

Special <7:0> :==IR<7:0>, 

MQ\Mul tipi ier. Quo tient<0 : 1 1>, 

ACC\Acc\imulator<0 : 11>, 

DACC\Double.ACC<0 : 23> :=Acc<0 : 1 1>@MQ<0 : 1 1>, 

CCodes[0:3]<> ;=PSW<1 5; 1 8>, 

In the above examples, several fields of IR have been 
defined as if they were independent registers (i.e. each field 
has its own name, with an optional alias, and a structure or 
dimension specification) . The bit (or word) names used on the 
left hand side of a field specification are independent from 
the bit or word names used on the right had side. Both sides 
of a field definition must, however, specify structures of the 
same size (# word * # bits/word) . The equivalence between the 
bits of the right hand side and the bits in the left hand side 
is obtained by aligning the leftmost bit of the leftmost word 
of’ the left hand side with the leftmost bit of the leftmost 
word of the right hand side. Thus, bit 4 of 10. BITS corres- 
ponds to bit 12 of IR, bit 3 to bit 11, bit 2 to bit 10, etc., 
etc. . 


In the second example, DACC<0:23> is defined as the con- 
catenation of two registers, MQ and ACC. The registers ap- 
pearing on the right hand side of a register definition might 
in turn be defined as subfields or concatenations of regis- 
ters. Definition chains of this sort can be of arbitrary 
length. 


The last example shows how different structures can be 
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mapped on top of a previously declared register. CCODES is 
defined as an ARRY of 4 1-bit registers. Thus, one can access 
the bits in the field PSW<15:18> using two alternative struc- 
tures (i.e. an array of 1-bit registers or a 4-bit field) . The 
equivalence of bits is as follows: The leftmost bit of word 0 

of CCODES corresponds to bit 15 of PSW. Since this is the 
only bit of word 0 , we continue on word 1 , whose bit corres- 
ponds to bit 16 of PSW, etc., etc.. 


3.5 BEHAVIORAL EXPRESSIONS 


b-expression ; := s-action 

s-action : := p-action-LIST NEXT 

p-action ::= action-LIST; 

A b-expression defines the behavior of an entity, b-ex- 

pressions are built by specifying the sequence of transforma- 
tions and transfers of values stored in carriers . Simple 
b-expressions (actions) can be combined to build larger b-ex- 
pressions by activating them in sequence (s-actions separated 
by NEXTs) or concurrently (p-actions separated by ';’). 

A<-1; NEXT C«-3 

In the above example the first two transfers are executed 
in parallel and then, after their completion, the third one is 
performed. No synchronization must be assumed between paral- 
lel actions. Actions separated by are considered to be 

'order independent' and can be executed in any fashion, even 
sequentially. In particular, this means that one can not 
assume rules like; "all right-hand sides are evaluated first 
an then all transfers take place" . The only requirement is 
that parallel actions are completed before proceeding beyond 
the following NEXT separator. 
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ACTIONS 

action : ;= c-expression i 

identifier := action! 
control-actxon 1 
conditional-action ! 

BEGIN b-expression END 

Actions are used to build complex behavioral expressions 
ranging from a primitive c-expression, to conditional or 
unconditional control flow operations, to a complex b-expres- 
sion inside BEGIN/END pairs. The latter type can be used to 
build arbitrarily nested b-expressions . As in the case of an 
e-body, BEGIN and END can be replaced by ' (' and 

. . .NEXTa-^1 ; B^2 NEXT (C-^3 NEXT D«-4); E-^5 NEXT 

A-4-1 and B-^2 are executed in parallel. Then, the 
sequence C-^3 followed by D«-4 is executed in parallel with 
E<-5. 


Actions may be labelled to allow the description of com- 
plex activxtxes, including selection and premature termination 
or reinitialization of actions . 

X := BEGIN END 

The BEGIN/END brackets used to build compound actions can 
be optionally followed by a quoted- text or block name to 
provide the reader with some degree of visual identification 
of the levels of nestxng; 

X : = 

BEGIN I this is the outer block f 

BEGIN / this is the inner block f 
END ! this is the inner block / 
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END / this is the outer block / 

The quoted-texts attached to matching BEGIN/END pairs 
must be identical. 


CONDITIONAL ACTIONS; IF and DECODE 

conditional-action : ;= IF c-expressxon => action! 

DECODE c-expression =>BEGIN 
numbered-action-LIST ' END 
numbered-action action I 

name-pair := action I 
[name-pair-LIST* ] := action! 

OTHERWISE ;= action 

Two operators, IF and DECODE, are used to specify condi- 
tional actions . If the value of the c-expression associated 
with an IF operation is non- zero the action follov/ing the => 
operator is executed, otherwise it is skipped. 

IF Acc EQL X => PCfPCt2 
IP Z => BEGIN END 

In the first example, the operator EQL defines a 1-bit 
result (0 stands for FAULSE, 1 for TRUE) . -Depending on the 
value of this bit, PC is incremented (1) or not (0). The 
second example shows that in general, the c-expression does 
not have to be 1 bit long. The action following the '=>' will 
be executed xf ANY bit in the Z carrier is 1 (i.e. Zf^O) . 

The c-expression associated with a DECODE operator is 
evaluated and its value used to select one of the actions 
specified in the numbered-action-LIST' following the => opera- 
tor. The c-expression is treated as an unsigned value. As in 
previous cases, the BEGIN/END brackets for the list of alter- 
natives can be enclosed in ' {* and ') '. 
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DECODE OP<1:0> => 
BEGIN 
ACC«-0 , 

ACC«~ACC+M[Z] , 

M[Z]^ACC, 

PC«-M[Z] 

END 


IOP<0; 1> is 0 
!0P<1 :0> is 1 
I0P<1 :0> is 2 
10P<1 :0> is 3 


When the DECODE operation specifies a large niainber of 
numbered-actions , xt is sometimes difficult for a reader to 
associate the numbered-actions with the values of the c-ex- 
pression whxch select them. In ISPS one can explicitly write 
the value of the c-expression associated with the action as a 
label-lxke action selector: 


DECODE OP<1:0> => 
BEGIN 

0 ;= ACC4-0, 

2 := M[Z]-^ACC, 

1 := ACC^ACC+M[Z] 

3 PC«-M[Z] 


! IF OP<1:0> is 0 
! IF OP<1:0> is 2 
! IF OP<1:0> is 1 
! IF OP<1:0> is 3 


Notice that in the example we have' altered the order of 
the actions. If explicit action selectors are used as in the 
example, one is free to write the actions in any order. For 
instance, when describing the instruction decoding in a com- 
puter, one might wish to group all the ADD instructions (half 
word, full word, double word, floating poinr, etc) , followed 
by all the SUBTRACT instructions, etc. even though the 
operation codes are not consecutive. 

A constant used to select a numbered-action identifies 
the value of the c-expression associated with the action. A 
name-paxr used to select an action identifies a set of values 
of the c-expression associated with the action. The operator 
OTHERWISE is used to define a default action if the outcome of 
the c-expression is not covered by the other action-selectors. 
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If a constant appears in more than one action selector (either 
alone or as part of a @ [name-pair] ) only the first action 
associated with the constant is executed (i.e. exactly one 
action can be executed as a result of a DECODE operation) . 
Another use of the explicit selectors is given below: 

Decode F => 

BEGIN 

0 := CR«-M[S], 

1 := CR-e-CR+M[S] , 

■ 2 := ACC<$- -M[S] , 

3 := M[S]4-Acc, 

4;5 ;= ACC-^ACC-M[S] , 

6 := IF ACC LSS 0 =>CR<-CR+1 , 

7 := STOPO, 

END NEXT 

Notice that there are two operation codes (4 and 5) 
associated with the Subtract operation. 

It is a bad practice to mix actions with implicit and 
explicit action-selectors. The syntax allows it to handle the 
situation in which a designer is not yet sure of the proper 
constant action-selectors to use and wants to go ahead devel- 
oping the ISPS description. 

The basic rule to remember is that ALL outcomes of the 
c-expression must be accented for. OTHERWISE must be used in 
some action if the number of actions is less than the number 
of possible values of the c-expression. 

CONTROL ACTIONS: REPEAT, LEAVE, RESTART, and RESUME 

control-action : : = REPEAT action ! 

LEAVE identifier / 

RESTART identifier I 
RESUME identifier v 
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An action that must be executed repeatedly (a loop) can 
be described by the use of the REPEAT operator preceding the 
action: 

ICycle ;= IPDP-10 Instruction Cycle 

BEGIN 

REPEAT 

BEGIN 

IR<— Memory [Pc] NEXT 
Pc«-Pc + 1 ;VAM<.IR<13:35> NEXT 
EA«~VMA()<18:35> NEXT 
lExecute ( ) 

END 

END 

A looping action can be terminated by the use of the 
LEAVE operator as the following example shows: 
iMndirect <>:= V?1A<13>, 

X\IndeX<0 : 3>:=VMA<1 4 : 1 7>, 

Y\Of fset<0 : 1 7>:=VMA<1 8 ; 35>, 

VMA\ Virtual Memory Address<1 3 : 35> := lPDP-10 
BEGIN • . 

REPEAT 

BEGIN 

IF X=>Y4- Reg [X]+Y NEXT I add the index register 
DECODE I => 

BEGIN 

0:= BEGIN VMA<1 3 : 1 7>«-0 NEXT LEAVE VMA END, 
1:= VMA-^Memory [Y] <1 3 : 35> [indirect address 

loop 

END 

END 

END 


The LEAVE operator is not limited to loop termination. It 
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can be used to terminate the execution of any labelled action. 
The LEAVE operation must occur inside the action to which the 
label refers. It causes control to terminate that action, and 
continue normally, as if the action had been completed (any 
actons initiated during the execution of the action to be 
terminated and not yet completed are also terminated by the 
LEAVE operator) . 

The following 'procedure' searches the first 512 words of 
Mp for KEY: 

S(Key<0:3»<> : = 

BEGIN 

INDEX<-0 NEXT 
REPEAT 

BEGIN 

IF MP [Index] EQL Key =>(3-^1 NEXT LEAVE S) 

NEXT 

INDEX «• INDEX+1 NEXT 

IF INDEX EQL 512 => (S<-0 NEXT LEAVE S) 

END 

END ! end of S 

The reactivation of an executing action can be forced by 
using the RESTART operation to indicate a termination of the 
action (as in the LEAVE operation) followed by a re-execution 
of the action. The RESTART operator must occur inside the ac- 
tion to be restarted (the pseudo LEAVE operation does cause 
termination of all actions initiated by the action to be re- 
started and not yet completed) . 

S(Key<0:3> <> := 

BEGIN 

INDEX<-0 NEXT 
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SI := BEGIN 

IF INDEX EQL 5 1 2 => (S^l NEXT LEAVE S) NEXT 
IF MP [INDEX] NEQ Key => { INDEX«- INDEX+ 1 NEXT 

RESTART SI) NEXT 

S«-1 NEXT 
END 

END ! end of S 

The RESUME operator provides another mechanism to termin- 
ate the execution of an action. As shown above, LEAVE is 
followed by the label of the action to be terminated. RESUME 
is followed by the label of the action whose execution is to 
be continued. As with LEAVE, the RESUME operation must occur 
inside the action to which the label refers. Any actions in- 
itiated during the execution of the action to be resumed and 
not completed are terminated. The following example shows the 
use of RESUME. 

Interpreter := 

BEGIN 

NEXT 

IcycleO NEXT 

IF Error EQL 1 => BEGIN END NEXT 


END,, 

Icycle ;= 

BEGIN 

PC-^PC -f 2 NEXT 
IR^Rword(PC) NEXT 
DECODE IR<0:3> => 
BEGIN 


ACC^ACC + Rword(IR<4: 15>) 


END, 

Rword (Addr<0 : 1 1>) <0 : 1 5> := 


BEGIN 
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IF Addr GTR Upper. Bound => 

(Error-^ 1 NEXT RESUME Interpreter) NEXT 
Rword-^ MP[Addr] 

END, 


In the example, procedure Interpreter activates procedure 
ICYCLE which fetches , decodes , and executes the instructions . 
In doing so, ICYCLE activates procedure RWORD which is used to 
access the memory CMP) of the machine, RWORD checks that the 
memory address is in bounds before performing the access op- 
eration. If a boundary error is detected, a flag (ERROR) is 
set and the rest of the operation of ICYCLE is aborted {by re- 
turnxng to procedure Interpreter, at the point where it acti- 
vated ICYCLE). It is up to the ’resumed' procedure (INTERPRE- 
TER) to take the proper corrective action, if any. Notice 
that we could have let ICYCLE handle the error by terminating 
RWORD with 'LEAVE RWORD'. However, this would have meant that 
the ICYCLE procedure had to check the error flag (ERROR) after 
every call to RWORD. Depending on the size or complexity of 
the description, this might be undesirable - 

Beware that these operators affect the sequence of opera- 
tions and might be meaningless or unimplementable when used in 
parallel actions, e.g.: 

X := (.. .NEXT. . .B«-C; LEAVE X NEXT ...) 
is_ ambiguous since no order of evaluation can be imposed on 
B<->C: LEAVE X 

When 'LEAVE X' is executed, the transfer *B 4 C' may or 
may not have been executed. 


3.6 QUALIFIERS 


The qualifier set is used to specify lists of attri- 
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bute/ value pairs which are used to define, amplify or modify 
the semantics of an ISPS description. 

Example: 

ALU (F<0:3>, A<0:T5>, B<0 : 1 5» <0 : 1 5> {SPEED: 

250, MODULE: SN74181} := 

3.7 ISPS DEFINITIONS 

ISPS-definition ::= DEFINE identifier := q-setl 

DEFINE identifier ;= quoted- text I 
DEFINE identifier := constant I 
MACRO identifier m-parameter-set 
;= quoted-text I 
REQUIRE ISP quoted-text 

m-parameter-set nil! 

()l 

(identifier-LIST) 

The reserved keyword DEFINE is used to name a q-set, a 
constant, or a quoted-text. 

Define ROM := {MODULE; SN74 1 87; SPEED ; 40 }, 

Define MSIZE ;= 255, 

M1 [0;MSIZE]<0;3> {ROM>, 

The reserved keyword MACRO provides a simple mechanism to 
declare test strings that are to be substituted for instances 
of the identifier in the ISPS description. Optional parameters 
can be specified by enclosing a list of identifiers inside 
parenthesis. These "formal parameters" are matched by corre- 
sponding 'actual parameters' at the expansion site. 

The reserved keyword REQUIRE. ISP is used to signal the 
expansion of a an external file inside the ISPS description. 
The quoted- text describes the file name. The expansion takes 
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place at the point the REQUIRE. ISP construct appears; 
REQUIRE ISP I MINLISP[L410MB25] I , 


3 . 8 PREDECLARED ENTITIES 


The followxng entities are predeclared in the language: 
UNDEFINED 

UNDEFINED is a predeclared entity which has some struc- 
ture and exhibits some behavior, both unknown to the user, 
UNDEFINED<0 : 7> defines a carrier, 8 bits long, containing an 
undetermined value. Any number of "undefined" bits can be ob- 
tained by specifying a program bit range. 

UNDEFINED 0 activates an entity v;ith undetermined side 
effects. No assumptions about the values contained in ANY 
carriers can be made after an activation of UNDEFINED. Activa- 
tions of UNDEFINED are guaranteed to terminate after some un- 
determined amount of time. 

UNPREDICTABLE 

UNPREDICTABLE is a predeclared entity which does not have 
a structure but which exhibits a totally unpredictable behav- 
ior. It is different from UNDEFINED () in that the latter pre- 
serves the flow of control. An activation like UNPREDICTABLE () 
is not guaranteed to terminate or that upon termination, con- 
trol will return to the activation site. 

NO. OP 

NO. OP is a predeclared entity which does not have a 
structure and whose behavior has no side effects. NO.OP{) can 
be used as a null action. 
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STOP 

STOP is a predeclared entity which does not have a 
structure and whose invocation, STOP () , terminates the 
activation of all entitxes, including the invoking action. 

DELAY 

DELAY is a predeclared entity which does not have a 
structure and whose invocation, DELAY (c-expression) , does not 
have side effects. DELAY terminates its activation after a 
number of application-defined time units given by the value of 
the c-expression. 

WAIT 

WAIT is a predeclared entity which does not have a 
structure and whose invocation, WAIT (c-expression) , continu- 
ously evaluates the c-expression. WAIT terminates its acti- 
vation when the value of the c-expression is not equal to 0. 


3.9 RESERVED KEYV/ORDS and IDENTIFIERS 


AND 

DECODE 

DELAY 

EQL 

EQV 

GEQ 

GTR 

IF 

K 

LEAVE 

LEQ 

LSS 

M 

MOD 


when attached to a constant 


when attached to a constant 



-6 3 


NEQ 


NEXT 


NOT 


NO. OP 


OC 

when 

OR 


REF 

when 

REPEAT 


RESTART 


RESUME 


SLO 


SL1 


SLD 


SLR 


SM 

when 

SRO 


SRI 


SRD 


SRR 


STOP 


TC 

when 

TST 


UNDEFINED 


UNPREDICTABLE 


US 

when 

XOR 


WAIT 



used as qualifier 
used as qualifier 


used as qualifier 

used as qualifier 
used as qualifier 


3.10 THE COMPLETE MINICOMPUTER 


An example description. 
Mini := 

BEGIN 


** Memory State ** 
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MP\Primary Memory [0:255] <0:11>, 

** Processor State ** 

PC\Program Counter<0 : 1 1 > , 

ACC\Acciamulator<0 ; 1 1 > , 

IRMnstruction Register<0 : 1 1>, 

OP\Operation<0 : 2> := IR<0:2>, 

^Indirect BitO:=IR<3>, 

ADR-$->»Address<0 : 7>:=IR<4: 1 1>, 

** Effective Address Calculation ** 

ZNEffective Address<0:7> ;= 

BEGIN 

DECODE IB IT => 

0 := Z«- ADR, 

1 := BEGIN 

IF ADR EQL 0 => Z4r- MP[0] + 1; 

IF ADR NEQ 0 => Z<- MP [ADR] 

END 

END 

END, 

** Instruction Cycle ** 

IEXEC\Instruction Execution t— 

BEGIN * 

DECODE OP => 

0\AND:=ACC«“ ACC and MP [Z()], 

1 \TAD : =ACC-^ACC+MP [ Z ( ) ] , ! 2 ' s Complement Add 

2\ISZ:= ’Increment and Skip if Zero 

BEGIN 

MP[Z]^ MP [ZO] +1 NEXT 
IF MP[Z] EQL 0 => PC<“ PC +1 
END, 

3\DCA:= MP[Z()3@ACC ^ ACC@#0000, iDeposit and 

Clear ACC 

4\JSR:= BEGIN IJump to SubRoutine 

Mp[0]-e-MP[0] + 1 NEXT 
MP [MP [ 0 ] ] <e-PC NEXT 
PC-4-Z 0 
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END^ 

5\JMP*= PC - Z() 
6\RET;= BEGIN 


! JUMP 

IRETurn from subroutine 


PC ^ I-IP [MP [0] ] NEXT 
MP[0] MP[0] - 1 

END, 


7\CTL:= 


BEGIN 


IF IR <3> => PC«- PC +1 NEXT 
IF IR <4> => ACC<- NOT ACC NEXT 
IF IR <5> => ACC<r- ACC +1 NEXT 
DECODE IR<6:7> => 

BEGIN 

'10 ;=ACC«-ACC SRO 1, 

'01 ; =ACC^ACC SLO 1 , 

OTHERWISE := NOOP ( ) 

END NEXT 

IF IR<8> => IF ACC LSS 0=> PC4-PC+1 ; 
IF IR<9> => IF ACC EQL 0=> PC<-PC+1 ; 
IF IR<10>=> IF ACC GTR 0=>PC«-PC+1 
NEXT 

IF IR<11> => STOPO 


END, 

ICYCLE\lnterpretation Cycle := 
BEGIN 
REPEAT 
BEGIN 

IR«- MP[PC] NEXT 
PC^ PC + 1 NEXT 
lEXEC ( ) 


END 
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3.11 ISPS SIMULATOR 

The conunand set of the simulator is summarized below; 

START <label list> begins the simulation of procedures in 
label list. 

EXIT terminates the simulation. 

READ <dev: filename> enables the simulator to read and 
execute commands from the specified device. 

DUMP IS used to save the status of a simulation run. 

DEFINE name = command- string $ defines a user command 

<name>. After this definition, the user can simply 
use <name> as a command to execute the corresponding 
command- string. 

pPEFINE name deletes the user defined command. 

TELLDEFINE prints the list of user defined commands. 

pO. command- string $ label, label,.... defines a com- 

mand-string to be invoked when any of the procedures 
listed after the $ is entered. 

ADO is similar to DO, but invokes the command-string 

when the procedures are terminated. 

ECHO (DECHO) command sets (resets) an internal flag control- 
ling the ECHOing the commands being read from a com- 
mand file to a user terminal.. 

RADIX <base> is used to set the numeric base. 

CONTEXT <varname> defines <varname> as a prefix for all names 
that are typed in future commands . 

CTR <name> displays the value of the counter (s) assoc- 
iated with <name>. 

OPAQUE <label list> and POP AGUE <label list> are used to in- 
hibit or enable the variable and label activity 
counters . If a procedure is OPAQUE then no activity 
counts are incremented during its execution. 

VALUE and SETVALUE commands are used to set and interrogate 
the contents of ISP variables. 
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TRACE ( DTRACE ) <varlist> enables (disables) the tracing of 
variables during simulation. 

BRAKE (ABRAKE) <label list> is used to enable the setting of 
Break points before (after) a procedure is excuted. 

DBRAKE ( DABRAKE ) disables the break-point setting. 

ICQNHECT ( OCONNECT ) <identif ier> , <channel>, <variable> 

is used to connect ISP variables to the system files 
which will act as sources (sinks) for variable values. 

EVE RY ( AEVERY ) count label, label,... forces a breakpoint 
every <count>th time one of the named procedure is 
entered (completed) . 

ONCE (AQNCE) are similar to above except the breakpoint is 
forced only once after the <count>th time. 

HELP tells the user about command names and their foinnat. 

WAIT makes the simulator to continuosly test the register 

used as parameter to wait until it is non-zero and 
then continue the execution. 

DELAY procedure takes as parameter the number of simulated 
time increments that should go by before operations 
on this procedure continues. 

SERIAL and PARALLEL accept procedure names as parameters and 
cause the register transfer code belonging to the 
named procedures to be SERIALized or unserialized. 

PROCESS label-list (dentifies all procedures in the label- 

list as processes: DPROCESS undoes PROCESS. Any time 
a routine flagged PROCESS is called from ISP, an 
autonomous operating environment for that process is 
initiated. The caller continues without waiting for 
a signal from the called process, and may even ter- 
minate without further affecting the new process. 

CRITICAL <label list> tags the procedures in label list to be 
non-interruptable. DCRITICAL clears this tag. 

INITIATE (KILL) <label list> initiates (terminates) the list 
of processes in the label list. 

TIME (DTIME) begins (terminates) the simulator's timing 
facility. 
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SETCLQCK <procedure> <value> sets the clock for that proce- 
dure at the new value. Each procedure in ISP has its 
own clock which increments as the register transfers 
proceed. 

OPTIME <op-label> = <value> is used to establish the times 
associated with the individual register transfer op- 
eration. The default value for each is one. 



4. A HARDWARE PROGRAMMINNG LANGUAGE (AHPL) 


AHPL is based on the notational conventions of APL. Some 
special conventions are added to APL to take care of the hard- 
ware features like parallelxsm;. asynchronous transfers and 
conditional transfers [16,17]. AHPL is a clock mode register 
transfer level language with the register as the primitive 
circuit description element. A hardware compiler capable of 
generating a wire list specifying the interconnection of 
available integrated circuits and a functxonal simulator which 
interprets the AHPL description and executes the connections 
and register transfers [18] are available. 

AHPL is based on the philosophy that a digital system can 
be divided into two parts: a control section and a processing 

section. Specification of the processors is done at one level. 
Hierarchical descriptions of both structural and functional 
elements are possible through the siibroutine feature of the 
language. Both parallel and sequential operations can be de- 
scribed, either by suppressing timing information completly or 
including it to a suf f xciently high degree . Synchronous de- 
scription facilities include tests for pulses and counting of 
pulses and delays. Asynchronous operations can be represented 
either by conditional statements or by implementing completion 
signals and usxng WAIT to indicate delay. The language as 
accepted by the compiler and the simulator [19] is described 
below. The simulator (HPSIM) is written in FORTRAN. The compi- 
ler (HPCOM) is written in SNOBOL. Borh are implemented on 
CDC-6400 and DEC- 10 systems. 
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4 . 1 SYNTAX RULES 

VARIABLES ; 

Variable names may contain up to 20 characters , the first 
of which must be alphabetic. The remaining may be nximeric or 
alphabetic. Only the first 10 characters are retained in the 
translator and simulator. 

CONSTANTS ; 

Constants may be entered in decimal. A vector of binary 
constants should be separated by commas and placed in back 
slashes . 

Examples : 

\ 1 , 0 , 1 , 0 , 1 \ 

25 

OPERATORS ; 

The following operators are allowed: 


AND 

& 


OR 

+ 


Exclusive-OR 



ALL BITS OR 

+/ 


ALL BITS AND 

&/ 


ENCODE 

$ 

Ex: 5$13=/0,1 ,1 ,0,1/ 

TRANSFER 

<= 

(2 characters) 

BRANCH 

=> 

(2 characters) 

COMPLEMENT 



CONCATENATE 

i 


CONNECTION 

— 
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4 . 2 DECLARATIONS 


Each AHPL module description begxns with the declara- 
tions, the first statement being, 

AHPL MODULE: module name. 

The rest of the declarations have the format 

TYPE : symbol <n> [m] ; symbol <n>, [m] 

where the TYPE can be MEMORY, INPUTS, OUTPUTS, BUSSES, EXIN- 
PUTS, EXBUSSES, or CLUNITS. The integers n and m indicate the 
niimber of rows and columns of the facility. Either one or both 
n and m can be eliminated if their value is 1 . They can also 
indicate a range n1:n2, m1:m2. 

MEMORY, BUSSES, ONESHOTS and CLUNITS are local symbols. These 
are declared in each module they are used. When redeclared in 
^ other modules, these refer to a new value location. 

INPUTS and OUTPUTS are semilocal symbols. When these symbols 
are redeclared in other modules, they refer ro the same value 
location. 

EXINPUTS and EXBUSSES declare Global symbols which can be 
valued externally and are common between all modules. 


4 . 3 CONTROL SEQUENCE 


The control sequence consists of a list of steps; each 
step starting with a step number followed by valid operations, 
separated by semicolon and ending with a period. For example, 

3 AC <=IR&AC; OUT = MD; 

=> (AC[0:3] )/(2, 3,5,6) . 

indicates a transfer, connection and a branch. The branch is 
to the statement 2,3,5 or 6 according to the value of AC [0:3] 
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is 8,4,2 or 1 respectively. Three forinats are possible for 
branch operation: 

=> (destination) unconditional 

=> (expression) / (destinations) multiple branch 

=> operator (expressioni , expression 2) (destination) 

Where operator is the comparison operator betv/een ex- 
pressions 1 and 2 and can be NE, EQ, GT, GE, LT and EE. 


4.4 COMBIHATIONAL LOGIC UNITS (CLUNIT) 


User can define combinational logic units at the beginn- 
ing of the description and can use them later. A partial 
CLUNIT description of a 4 bit adder is shown below: 

UNIT; CLADD (A,B,CIN) 

INPUTS; A [4]; B[4];CIN [1]. 

OUTPUTS: CLADD [5] . 

CLUNITS: PG [3], SUM [1], CLA [6]. 

1. I <= 4 

2. C [I] = CIN [0] 

3. I <= 1-1 

4. NOTP[I], P[I], G[I]= PG[0;2] (A[I] , B[I]). 

5. S[I] = SUM[0] (NOTP[I], P[I], C[I+1]). 

6. => NE (1,0)/ (3) 

7. I <= 12 


END. 


The CLUNIT description starts with a UNIT:, followed by 
the module's name and the argument list, input and outputs 
for the module are identified. Any other CLUNIT used in the 
module is then identified. The description ends with an END. 
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Each CLUNIT is a module that can be used in the description of 
the system. Facilities exist to imply several copies of the 
module (rather than sharing the module) in the description of 
the system. 


4 . § COMMENTS 


Comments can be placed anywhere in the AHPL sequence. 
They should be enclosed in do\±)le quotes. 


4.6 SIMULATOR (HP SIM) 


The communications with HPSIM follow the hardware des- 
cription and include the following commands: 

CLOCK LIMIT : 

Tells HPSIM, the number of clock periods for which ex- 
ecution is to continue, if it 'does not reach a DEAD END. 

BUSEFFECT — nn : 

Is used to assign values to the external inputs or 
busses. nn is the number of clock periods for which the cor- 
responding line receives the values from the cards following 
the BUSEFFECT command. 

OUTPUTS t 

Enables printing the values of selected variables during 
the simulation. 

SUPPRESS ; 

Command is used to suppress the printing of results dur- 
ing a specified step in the control sequence. 



4.7 DESIGN EXAMPLE [19] 


To illustrate the preparation of a circuit description 
for HPSIM and HPCOM consider a sample multiplier circuit with 
nine input lines and nine output lines as shown in Figure 4-1 . 
In the reset state it waits for a 1 on line DATAREADY, which 
indicates that data is on the INPUTBUS lines. The four most 
significant bits of INPUTBUS are the first operand and the 
other four consititute the second operand. When the operands 
are accepted, the BUSY flip-flop as set to one and the multi- 
plier starts the multiplication process. When done, BUSY is 
set back to zero, and the eight bit result is placed on the 
eaght RESULT lines and a one on the DONE line. Then the multi- 
plier goes to the reset state waiting for another set of 
data. 


Figure 4-2 shows the input file to HPSIM. the first line 
in this fagure assigns a name to the module description. This 
is followed by declaration of all lines and registers. The 
circuit requires three four-bit registers for the two operands 
and the intermedaate results, a single flap-flop for the DONE 
indacator, and a two bit counter for the number of bits 
shifted out of the first operand register. The lines to be 
assigned values by the user are DATAREADY and INPUTBUS, These 
are, therefore, declared as EXINPUTS and EXBUSES respectively. 
The last of the declarations, CLUNITS, indicates the presence 
of combinational logic networks implementing a 2~bit incre- 
menter and a 4-bit adder. 

The circuit AHPL sequence follows the declarations. Step 
1 receives the operands, resets the intermediate register 
(EXTRA) . If there is a 1 on the DATAREADY line control pro- 
ceeds to Step 2; otherwise. Step 1 remains active. Step 2, 












AHPLMOriULE : MULTIPLIER . 

MEMORY;AClC43fflC2C43JCDUNT[:23»EXTRAC4a»BUSY. 

exinputs:dataready. 

EXBUSES : IHPUTBUSCaS . 

OUTPUTS ;RESULTCa3f done. 

CLUN1TS:TNCC23 (COUNT) JADDCSO (EXTRA! AC2>. 

1 AC1»AC2 <=> INPUTBUSC0;33»INPUTBUSC4!73i EXTRA <= 4*0! 
»> (~ DATAREADY)/(1) . 

2 BUSY <» \1\J 

“> (“ACIC30)/(4) . 

3 EXTRA <= ADDCl !43 (EXTRA !AC2) . 

4 EXTRA»ACI <= \0\ .EXTRA »AC1C0 !23 ! COUNT <= INC(COUNT)) 
=> (~(t/COUNT> )/(2) , 

5 RESULT » EXTRA. ACl! DONE = \1\) BUSY <= \0\! 

-> <1). 

ENDSEQUENCE 

CQNTROLRESETd). 


END. 


CLQCKLIHIT 

0030 

EXUNES; 


BUSEFFECT 

0021 

0400010 


BUSEFFECT 

0021 

0410132 


BUSEFFECT 

0021 

0000012 


BUSEFFECT 

0021 

7777700 


BUSEFFECT 

O 

o 

1.) 

7777777 


BUSEFFECT 

0021 

0000132 


BUSEFFECT 

0021 

4000100 


7USS-FECT 

0021 

7‘’7’'746 


BUSE"ECT 

0021 


> ;oLS4 





■ ;jLT 


Figure 4-2; HPSIM Program input File 
for the Multiplier 


AHPL FUtCTrCfl LE'^rL EI"-ULnTOR OUTPUT IS LISTE.. Ll_:- 



' BUSY 

' ' DONS 


' i ' ! 

' I ! ! 

! ) ' ! 
CLOCK 4 I 1 I ! 

oooooooi 0 ooliolii 0 o 

00000002 0 00110010 0 0 

00000003 0 00110010 0 0 

00000004 1 10110010 0 0 

00000005 0 00110010 0 0 

00000006 0 00110010 1 0 

00000007 0 00110010 1 0 

OOOOOOOB 0 00110010 1 0 

00000009 0 10110010 1 0 

OOOOOOlO 0 00110010 1 0 

00000011 0 00110010 1 0 

00000012 0 00110010 1 0 

00000013 0 00110010 1 0 

00000014 0 00110010 1 0 

00000015 0 10111111 1 0 

00000016 0 OOOlOOll 1 1 

00000017 0 lOOllOOO 0 0 

coooooia 1 11011001 o o 

00000019 0 00010011 0 0 

00000020 0 11011010 1 0 

00000021 0 00010000 1 0 

00000022 0 00000000 1 0 

00000023 0 00000000 1 0 

00000024 0 00000000 1 0 

0000002E 0 OOOOOOOO 1 0 

00000026 0 OOOOOOOO 1 0 

00000027 0 OOOOOOOO 1 0 

00000023 0 OOOOOOOO 1 0 

00000029 0 OOOOOOOO 1 0 

00000030 0 OOOOOOOO 1 1 


EXTRA 
I ACl 

! i AC2 

I 1 ! COUNT 

III' RESULT 
''111 
0000 0000 0000 00 OOOOOOOO 
0000 0011 0111 00 OOOOOOOO 
0000 0011 0010 00 OOOOOOOO 
0000 0011 0010 00 OOOOOOOO 
0000 1011 0010 00 OOOOOOOO 

0000 1011 0010 00 OOOOOOOO 

0010 1011 0010 OO OOOOOOOO 

0001 0101 0010 01 OOOOOOOO 
0001 0101 0010 01 OOOOOOOO 

0011 0101 0010 01 OOOOOOOO 
0001 1010 0010 10 OOOOOOOO 
0001 1010 0010 10 OOOOOOOO 
0000 1101 0010 11 OOOOOOOO 

0000 1101 0010 11 OOOOOOOO 
0010 1101 0010 11 OOOOOOOO 

0001 0110 0010 00 00010110 
0001 0110 0010 00 OOOOOOOO 
OOOO 1001 1000 00 OOOOOOOO 
OOOO 1101 1001 00 OOOOOOOO 
OOOO 1101 1001 00 OOOOOOOO 
1001 1101 1001 00 OOOOOOOO 
0100 1110 1001 01 OOOOOOOO 

0100 1110 1001 01 OOOOOOOO 
OOlO 0111 1001 10 OOOOOOOO 
0010 0111 1001 10 OOOOOOOO 
1011 0111 1001 10 OOOOOOOO 

0101 1011 1001 11 OOOOOOOO 
0101 1011 1001 11 OOOOOOOO 
1110 1011 1001 11 OOOOOOOO 
0111 0101 1001 00 01110101 


or 

i 


crccc program reached the time LIMIT SrECIPIED BY USER. 


Figure 4-3; HPSIM Output Listing for 
, the Multiplier 
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sets the BUSY flip-flop to 1 and causes Step 3 to be skipped 
if AC1 [3] , which is the LSB of ACI register, is zero. In Step 

3 the addition of the partial products is accomplished. Step 

4 right shifts the catenation of the EXTRA and ACI registers, 
increments the counter and activates Step 2 if count has not 
reached (1,1). If the COUNT register contains (1,1), control 
will proceed to Step 5 where the catenation of the EXTRA and 
ACI registers is placed on the 8 RESULT Lines, a one is placed 
on line DONE and the BUSY flip-flop is reset to zero. Step 5 
also returns control to Step 1 waiting for another set of 
operands . 

The communication section of the HPSIM program follows 
the AHPL description. Recall, that this secrion is line 
oriented. The first card, "CLOCKLIMIT" , indicates how long the 
execution is to be carried on. This parameter is set at 30, 
so that the multiplication process will be carried out at 
least twice. The "EXLINES:" card is a heading for the subsec- 
tion in which binary values are assigned to the external input 
lines. The next 18 cards are 9 sets of data for all 9 exter- 
nal lines. Each data set is headed by a "BUSEFFECT" card 
which indicates the number of clock periods for which the cor- 
responding external line is to receive data. The nth data set 
corresponds to the nth declared external line. For example, 
since the first declared external line is DATAREADY, the first 
data set, which is 0400010 (octal), is assigned to this line. 
This line will receive binary data from this data set for the 
first 21 clock periods. The data for the 7th most significant 
line of INPUT-BUS is 7777746. This line also receives data 
from this set only for the first 21 clock periods. The next 
card in the communication section "OUTPUTS", is a heading for 
the print request subsection. The next five cards are the 
lines or registers for which print is requested. If a row in a 
register matrix is to be printed, the row n\rtiber should follow 
the name of the register matrix- on the same card. Row number 
zero is the default value which is assumed for all one dimen- 
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sional lines or registers. All print requests are unformatted 
and the printout format is set by the HPSIM system. The com- 
plete output sequence is shown in Figure 4-3. Notice that 
DATAREADY is 1 during the 4th clock period causing control to 
go to Step #2 for period 5, the two operand registers (AC1 , 
AC2) containing 1011 and 0010. The multiplication starts at 
period 5 and ends at clock #16 where a 1 appears on the line 
DONE indicating that the 8 RESULT lines have the result of 
multiplication. Notice that a nev; partial product appears at 
clock periods 1 , 10/ and 15 to be shifted right by the next 
clock pulse. Only a rxght shift takes place after period 12. 

A second raultiplica tion begins at 19 and is completed at Step 
30 where DONE = 1 and the product appears on the 8 RESULT 
lines . 

All but the communication section of Figure 4-2 is the 
input file to the HPCOM program. 

For this example, the compiler printout in Figure 4-4 
lists first the clock and data inputs for the data registers. 
Next are the gates realizing each module output, and last are 
the D inputs to each control D flip-flop. The remaining com- 
piler output detailing inputs to each gate is given in Figure 
4-5. They are in numerical order showing type on the left, and 
the inputs either as control signals or source gates on the 
right. 

Using the information of Figure 4-4 complete schematic 
diagram such as the one shown in Figure 4-6 may be obtained. 
Figure 4-4 shows the registers listed first with the segment 
under consideration given at the left edge followed on the 
same line by the clock enable. This signal is gated with the 
clock should the register type used, not have an enable input 
provided. {The full schematic of Figure 4-6 shows these gates 
with a dot. ) Further right are the individual data inputs for 
each bit of the register segment. They are listed by bit, on 
the left, and gate or signal implementation on the right. 
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TKGS, IS 
Q£ QUAIST^ 


CC*1PILER rOR AHPL 

harduare routines. 

HAY 13f 1977. 


REGISTER 

CLOCK 



segments 

ENABLE 

REGISTER BIT 

INPUT SOURC 

:co;33 

01 

AC1C03 

G< 



AC1C13 

Q7 



AC1C23 

GlO 



AC1C33 

613 

AC2E0;33 

CSC13 

AC2E03 

61-4 



AC2C13 

G15 



AC2C23 

GlS 



AC2C33 

617 

3USYE03 

GIS 

BUSYC03 

CSC23 

C2UNTC0;13 

CSC43 

C0UNTC03 

Gl9 



COUNTCII 

620 

£XTRAC0;33 

G21 

EXTRAC03 

G22 



EXTRAC13 

G2S 



EXTRA C23 

623 



EXTRA C 33 

631 

CONNECTION 




SEGMENTS 


OUTPUT BIT 

terminal 


,r=SULTEO:73 




PESULTC03 

632 



RESULT Cl 3 

633 



RESULTC23 

S3 4 



KESULTC33 

63S 



RESULTl43 

C36 



RESULTIS: 

637 



RHSUL7Co3 

QoS 



RESULTCTj 

G39 



BQNECO: 

CS2S3 

CCNTRCL BIT 

D INPUT 



ZZ'Zl 

G*T-^ 



- - - - 

3— S 



.. To" 

C--S 




Z 




=• 

-r £ 



Ti“ 1 ” ZZ- 

. L-‘CSE 


,7“ 13 

ZQ*-^EZ7Z3 7Z ^-3T3= 

4 , 



Figure 4-4: HPCOM Output 
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GATS 

GATS 


TYPE 

NO. 


OR 

61 

CSC13 

AND 

G2 

csci: 

-AND 

33 

CSE43 

CR 

34 

G2 

AND 

35 

AC1C03 

AND 

G6 

CSC13 

OR 

G7 

GS 

AND 

G3 

AC1C13 

AND 

G9 

CSC13 

OR 

GIO 

GG 

AND 

Gll 

AC1C23 

and 

G12 

CSC13 

OR , 

G13 

Gll 

AND ' 

G14 

CSC13 

AND 

G15 

CSC13 

AND 

G16 

CSC13 

AND 

G17 

CSCID 

OR 

G18 

CSC2D 

AND 

G19 

CSC 43 

AND 

G20 

CSC43 

OR 

G21 

CSC13 

AND 

G22 

ADDC13 

AND 

G23 

ADDC23 

AND 

334 

CSC43 

OR 

625 

G23 

AND 

62o 

ADDC33 

AND 

G27 

CSC43 

OR 

G23 

G24 

AND 

G29 

ADDC43 

and 

G30 

C3C43 

OR 

G3i 

G29 

AND 

332 

CSC33 

AND 

332 

CSC33 

AND 

334 

CSCS3 

AND 

G33 

C3C53 

AND 

G3i 

AC1C03 

AND 

G37 

AC1C13 

AN D 

3o3 

Acic::3 


C29 

AC1C33 


Q40 

count: 03 


041 

G40 

'' r* 

Q-t*’ 

C3C43 


Z 

CSC13 

->* 


ZA2 


3 *• 3 

C3 r« - 


3*^0 

AC I, CZZ 

- ' 

C** 7 

Dft7x=£4r' 



C3CI 3 

, ■ 

-..o 




Ar- 


3“ * 


- ■ 

zzz 

C3:C3 


data inputs 


CSC43 

INPUTBUSC03 
EXTRA Co 3 
33 
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5. DIGITAL SYSTEM DESIGN LANGUAGE (DDL) [20] 


DDL was introduced in 1968 by Duley and Dietmeyer [21, 

22] . A translator and a simulator are written for a subset of 
this language in IFTRAN an extended version of FORTRAN [23, 

24] . These programs are being implemented in FORTRAN on SEL 32 
Computer System. DDL is a "block oriented" language^. Each 
subsystem of a system appears as a block in the description of 
the system. The following sections introduce the language as 
required by the translator and simulator. DDL is suitable for 
the intermediate level of description between the extremely 
abstract level and the fabrication level. 

All structural elements are explicitly declared. At the 
lower level of description, functional and structural elements 
correspond directly to the actual elements of the system. DDL 
is highly suitable for describing the system at the gate, re- 
gister transfer and major combinational block level. 

The logical statements can be formed using the available 
primitive operators. The functional specification of the 
system consists of these logical statements, in blocks. The 
statements describe the state transitions of a finite state 
machine controlling the processes of the intended algorithm. 
The block then appears as an automaton. 

Parallel operations are permitted. Synchronous behavior 
is described by either identifying the pulses or by including 
delay elements described in terms of multiples of clock 
pulses. Asynchronous behavior is modelled by using conditional 
statements. Data paths can be explicitly declared by using 
terminal declarations . 
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5.1 SYNTAX RULES 


VARIABLES ; 

Variable name may contain 1 to 6 characters , the first of 
which must be alphabetxc. The remaining characters must be 
letters or digits . 

CONSTANTS : 

Constants take the general form nRk. n is the number in base 
R CR=D for decimal, 0 for octal) . k is the number of bits 
required for the representation k< or = 32. k is decimal - 


5.2 DECLARATION STATEMENTS 


The general format of a declaration statement is 
<DT> body . 

The declaration type (device) is enclosed in angle brackets 
and the perxod terminates the declaration. Body consists of a 
list of items separated by commas . Following devices are 
allowed: 


TEimiinal 

Sets of wxres 


REgisters 

Sets of synchronized 

flip-flops 

MEmory 

Sets of synchronized 

flip-flops 

LAtches 

Sets of asynchronous 

latches 

Time 

Clock 


DEI ay 

Delay elements 


Boolean 

Combinational logic 


ELement 

Off the shelf components 

<TE> X, Y(4) , 

Z (0:2) , W(3,4:1) , A(12) 

= B "C(0: 


identifies a single wire X, four wires , Y 2 , Y^ with Y^ 
on the left, 3 wires Zq, Z^, and 12 wires correspondxng to 
W, placed in 3 rows, ith row of wires numbered ^12' 
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The subscripts always have a left to right interpreta- 
tion. A single subscript n indicates the range 1 to n while a 
range n:m indicates n to m left to right. In the above 
declaration, is also named B, A(2:12) are named C(0:10). " 
is the concatenation operator. 


REgister and LAtch DECLARATIONS 

<RE> IR(16) = OP(0:3)" IX(1:3)" ADRS(9), X(12). 
declares a 16 bit register IR and a 12 bit register X. 

IR is identified with 3 subregisters OP, IX and ADRS. 
<LA> BUP(4) . 

declares a set of 4 latches BUF. 


MEmory DECLARATION 
<ME> M{X;Y) . 

declares X words (numbered from 0 to X-1) of Y bits each 
(numbered 1 through Y) . 

References to the memory must be of the form M(MAR) where 
MAR is the same register in all references to M. MAR is de- 
clared in a RE declaration. Only full words may be accessed 
from memories. 


Time DECLARATION 

<TI>A(lE-6), Q(20E-9)$2$. 

declares a single phase clock A with a 1 microsecond period 
and a two- phase clock Q with 20 nanosecond period. 


DElay DECLARATION 

<DE> P(10E-9) , Q(5E-7) . 

declares two delays P with 10 nanoseconds and Q with .5 micro- 
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second. The context in which the DElay element is referenced 
determines whether its input or output terminal is used. 


Boolean DECLARATIOM 

<B0> identifier = Boolean expression. 

For example, 

<TE> A, B(5), C(0:4), D(6, 5:1) 

<B0> D(4) = B+C, D(5) = A*B. 

declares that the fourth row of D is formed by ORing termi- 
nals B and C i.e. B^+ Cq etc.) bit by bit; the fifth row 

of D is a bit by bit AND of A and B. Since A is 1 wire and B 
is a set of 5 wires, A is fanned out to combine with each bit 
of B . 


ELement DECLARATION 

Enables the description of an element in the system whose 
logical specifications are unknown or impertinent. 

For example, 

<EL> JKFF (Q1,NQ1: C, J1 , K1 ) , COUNT (K(5;1), ZERO: 

UPDWN, CLK) . 

declares an element JKFF with 3 inputs C,J1,K1 and two output 
Q1 and NQI ; and an element COUNT with two inputs and 6 out- 
puts . The only information available on these black boxes is 
the input/output terminals . 


5 . 3 OPERATIONS 


Figure 5-1 (a) shows the operations allowed and their 
hierarchy; Figure5-1 (b) shows three special operators. 
is used to show the connections while <- indicates a data 
transfer from one facility to the other. -> is equivalent to 
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FIGURE 5-1 (a) : OPERATORS 


OPERATOR 

SYMBOL 

TYPICAL SYNTAX 

COMMENTS 

Extension 

$ 

A$k 

k copies of A 

Concatenation 

Tl 

A"B 


Complementation 

A 

AA 

Bit by bit 
complement 

Selection 

f 

A'kDn 

Selective com- 
lementation 

Reduction 

/ 

P/A 

A^pA2P. . .pA^ 
where pE[*,A* 
A+, A@ , @ 

AND 

■k 

A*B 

Bit by Bit 

NAND 

A* 

AA*B 

Opertions 

NOR 

A+ 

AA+B 


XNOR 

A@ 

AA@B 


XOR 

@ 

A0B 


OR 

+ 

A+B 


FIGURE 

5-1 (b) ; 

SPECIAL OPERATORS 



CONNECTION 
TRANSFER <- 

-> 


GO TO 


> 3 
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a "GOTO”, usually used to show the next state. 

The extension operator creates k copies of the ter- 
minal or terminal set offered as its left operand. 

The selection operator selectively complements, or not 
complements the bits of the facility (left hand operand) de- 
pending on the value of the corresponding bit in kDn is a 
0 , 1 . 



The operator preceding the reduction operator (/) 
determines the nature of the reduction on the right hand 
operator of /. Six types of reductions are possible. 
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+/A'3D5 implies 



Boolean expressions (Be) can be formed by using the 
operators and variables in the usual manner. Parenthesis 
could be used where there is an ambiguity. The expressions 
are evaluated from left to right following the operator 
hierarchy. 


Conditional operations have the format 
?BE? OP^ . or 
?BE? OP^; OP 2 . 

The first form implies: If the value of BE is 1, perform OP^ ; 
the second form implies: If BE is perform OP^ else perform 

OP 2 * "If ... then" operations can be nested; 

?A? ?B? OP^.; ?C? OP 2 .. 

5.4 IF - VALUE CLAUSE 


"i" is used for "IF" and "#va" is used for the value in 
an IF-value clause. For example; 

B = !C #0 DO #1 D1 #2 D2. 

implies that DO is connected to B if the value of C is 0, D1 
is connected to B if the value of C is 1 , etc . 

As another example, 

IX #0D2 A<-B #1D2 A<-C #2D2 A<-AB #3D2 A<-AC 
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describes a 4 way conditional transfer operation into A 
depending on the value of X. 


5 . 5 IDENTIFIER 


IDentifier declaration enables the naming of a group of 
operations so that they do not have to be written repeatedly 
(equivalent to MACROs) . The general format of IDentifier 
declaration is, 

<ID> list 

where list takes the « form 

id = compound facility 
id = (CSOP) 

For example, <ID> X = C(2:10)"1. names the compound facility 
C(2:10)”1 to be X. Then, any reference to X is expanded into 
C(2: 10) "1 , 

For example, S = R © X. is equivalent to S=R®C(2:10)"1. 

A compatible set of operations (CSOP) is a set of opera- 
tions separated by commas. It must be possible for the hard- 
ware to perform all these operations simultaneously. 

The order in which the operations are listed is of no 
consequence. For example, 

<ID> A = (Y <- X, Z <- Z (2:5) ”AZ (1) ) , 

B = (Y <- X, Z <- Y) . 

names two CSOPS. Note that the operations Y <- X and Z <- Y 
in B are simultaneous and are compatible. 
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5.6 OPERATOR DECLARATION 


Blocks of combinational circuitry can be defined with the 
operator declaration. The body of the Operator declaration 
consists of a BOolean declaration and perhaps a TErminal 
declaration. Boolean equations in the body of the BOolean 
declaration include Boolean expressions which may involve 
conditions and be relatively complex. References in these 
Boolean equations may be made to (1) facilities global to the 
operator declaration. (2) local terminals declared within the 
operator declaration by a TErminal declaration, and (3) ter- 
minals declared and dimensioned in the head of the Operator 
declaration. The TErminal declaration may be used to define 
local terminals of the operator, and must be used to dimension 
"dummy" identifiers listed in the heading, if any. 

The head of the Operator declaration consists of one or a 
list (separated by commas) of identifiers with or without an 
argument list enclosed in $s, with or without parenthetic sub- 
script ranges. Permitted syntactic forms for heads are; 
id^, id2(i2)^ , X2,...Xj^$, id^ (I4)? 

X^, X2... 

where subscript ranges can also be placed within the paren- 
thesis. The identifiers name the combinational logic blocks 
and their output terminals. Parenthetic integers dimension 
the output terminal sets with the same Syntax and semantics as 
in TErminal declarations. The argioments are local dummy id- 
entifiers of input terminals of the combinational blocks. Such 
dummy identifiers must be dimensioned via a local terminal 
declaration within the Operator body. 

As an example of a time- shared operator block, ALU is 
decalred below. This combinational block is able to add two 
16-bit binary sequences presented to it on lines X and Y or 
form their bit-by-bit EXCLUSIVE-OR. Input signal F determines 
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which task xs performed. The carry into rightmost full-adder 
must also be presented to the unit. 

<0P> ALU (16) $ X,Y, CIN, F$ 

<TE> X(16), Y(16), GIN, P, C(16) = CX"CC(15). 

<B0> C=X*Y + CC" CIN* (X+Y ) , 

ALU = (?F? X@Y@ CC'CIN; X@Y) . . (end of BO, end of OP) 

Note the inline comment capability of DDL (end of BO, end of 
OP) . 


Suppose the following declaration is global to ALU, 


<RE> ACC (16), MBR(16), COUNT (12) 


we can define several operations using ALU as following; 


?LDA? ACC <- ALU$0,MBR,0,0$ 

?ADD? ACC <~ ALU$ACC,MBR,0,1$ 

?SUB? ACC <- ALU$ACC,AMBR, 1 , 1$ 

?KNT? COUNT<- ALU ( 5 ; 1 6 ) $0 $ 4 "COUNT, 0 , 1 , 1 $ 

?XOR? ACC <- ALU$ACC,MBR,0,0$ 


5 . 7 STATE DECLARATION 


DDL views the operation sequencing (control) circuitry as 
a f unite state machine. Each state of the control circuitry 
is described by a STate declaration: 

<ST> State List . 

State list consists of a list of state statements (with- 
out separating commas) . Each state statement has one of the 
following forms : 

Sid (n) ; csop. 

Sid (n) ; Be; csop. 
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Sid is a simple iinsubscripted identifier, n is the deci- 
mal state assignment .csops include the state change operations 
using the state transition operator ->. 

In the fxrst form, csop is performed whenever the auto- 
maton is in the state Sid. 

In the second form, csop is performed when the automaton 
is in Sid and also Be is satisfied. The automaton waits in 
the state till Be is satisfied. 

A 15 bit multiplier control can be described as follow- 
ing: 

<ST> SO(0) :MPY:ACC<-0, CNT<- 1 5D4 ,->S1 . 

S1(1):->S2, DECR$ CNT$,?Q(15)? ACC<-ACC+R. . 
S2(2) :SHR$ACC"Q$, ?+/CNT?->S1';S0 . . . 

{end of conditional, end of S2, end of ST) 

SHR is shift right (zero fill) operator and DECR is a 
decrement operator assumed to be defined using <0P> declara- 
tion. 


5.8 AUTOMATON and SYSTEM DECLARATIONS 


Relatively independent disjoint portions of a digital 
system are identified as automata in DDL with syntax. 

<AU> head body. 

The Automaton declaration is the most complex type of 
declaration of DDL. Its head may take any of four forms, for 
example; 


auid: 

auid:csop 
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auid:Be: 
auid:Be: csop 

First, an automaton identifier, auid, may be subscripted, 
but may not include parenthetical arguments; it names the 
block only. A compatible set of operations may be included in 
the head of an automaton. These operations are to be per- 
formed whenever the Be of the heading, if any, is satisfied. 
Conditional as well as unconditional operations may be in- 
cluded in this heading csop, so whether a specific operation 
is performed or not may depend on conditions throughout the 
automaton or system. 

Be in the heading of the Automaton declaration is a 
condition on all operations declared throughout the body of 
the declaration except connection operations . Usually Be is 
the clock signal that synchronizes the automaton. It is 
generally unnecessary and undesirable to include such global 
conditions as clock signals in combinational circuits; in 
fact, signal propagation in combinational networks usually 
precedes clock pulses. If a clock with n phases is used to 
synchronize an automaton, then a dimensional Be or a conca- 
tenation of n Bes appears in place of the single Be in the 
Automaton declaration head. 

The body of an Automaton declaration consists of other 
declaratons . Each of these declarations is terminated with 
its own period; punctuation is not placed between them. The 
following declaration types may appear. 

<ME>, <RE>, <LA>, <TE>, 

<TI>, <DE>,<OP>, <EL>, <ID>, <B0>, <ST> 

ME, RE, LA, TE, TI , DE, AND EL declarations are used to 
declare the existence of local facilities of the automaton. 

The Operator and Boolean declarations specify combinational 
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blocks and interconnections of facilities. The IDentifier 
declaration may be used to simplify or clarify the overall 
Automaton declaration. The STate declaration is usually used 
to specify the operations of the automaton. If the STate 
declaration is not used, then all operations appear in the 
csop of the Automaton declaration head. 

The system declaration has syntax identical to the Auto- 
maton declaration. The system is identified in the head. 
Global coditions and csop may be specified also. The body of 
a SYstem declaration may contain Automaton declarations as 
well as all other types of declarations , but STate declara- 
tions must appear within Automaton declarations. Public 
facilities are declared with ME, RE, TE, etc,, declarations 
outside of all Automaton or Operator declarations. 

Example : 

A multiplier controller is described below to 
illustrate the SYstem and Automaton facilities. 

The counter is treated as a separate automaton. 
Perhaps other unspecified automaton of SYSTEM 1 
can use the counter when automaton MC is not. 

<SY> SYSTEM1 ; 

<RE> ACC(15) , Q(15) , R(15) . 

<TE> SET, DEC, DONE, MPY. 

<TI> P (IE-7) . 

<AU> CPU: P: 

<ST> . 


Q17: DONE: Q <- Multiplier, 

. R <- Multiplicand, MPY = 1. 


. (end CPU) 
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<AU> MC; P: 

<ST> SO: MPY: ACC <- 0, SET = 1, -> SI . 

SI: -> S2, DEC = 1,?Q[15]? ACC <- ACC+R. . 
S2: SHR$ACC"QS,?D0NE?-> SO; -> Si,.. 

<AU> K: P: 

<ST> [i=1:15] T(i): DEC: -> T(i-1).. 

T(0): DONE = 1,?SET? -> T(15); -> T(0)... 
(end SY) 


Automaton CPU is shown only as placing the multiplier and 
multiplicand in piiblic registers and issuing command MPY to 
multiplier control MC, If the counter automaton K is idle, it 
will be issuing DONE = 1. CPU waits in its state Q17 until 
this condition is satisfied (perhaps K is still doing a job 
for some other automaton) . MC clears ACC, but the counter is 
initialized by SET = 1 . Specifically SET = 1 will cause K to 
go from its state T(0) to T(15) where it will remain until it 
is told to decrement via public terminal DEC. MC tests the 
multiplier, adds or not and shifts repeatedly until it is 
informed by K via public terminal DONE that all multiplier 
bits have been examined. In the example above interacting 
automata MC and K operate in parallel. 

NOTE ; The "For clause" shown in the Automaton K for the 
decremnt operation [i=1;15] T(i):DEC; -> T(i-1) is not allowed 
in the present version of the DDL software. This statement 
has to be broken up into; 

T(1) : DEC; -> T(0) 

T{2) : DEC: -> T(1) 

• 

T(15) ; DEC; -> T(14) 

SHR is a single argument operator (assumed to be declared 
earlier) that shifts the argument one bit right, and fills 
zero on the left. 
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5 . 9 ADVANCED FEATURES 


The following features of DDL are not accepted by the 
present version of DDL software: 

(a) Shift and count operations. 

(b) SEGMENT declarations, which allow the Automaton 
to be broken up into several partitions. 


5.10 TRANSLATOR (DDLTRN) [25,26] 


DDLTRN translates a restricted DDL descrxption into a set 
of tables suitable for simulation of the system. It is a six 
pass translator performing a syntax check, facility identifi- 
cation, syntax reduction, condition distribution, concatena- 
tion removal, operation gathering ^nd disjoining the subfacil- 
ities. The FLAG statement can be used to control the printed 
output of the intermediate steps . 


5.11 SIMULATOR (DDLSIM) [27] 


DDLSIM uses the tables produced by DDLTRN to simulate uhe 
system. Multiple simulations are possible with the DDLSIM 
control statements. The following commands are available: 

<CLock> declarations provide a means of specifying or 
changing the time period, pulse width and phase of the clock 
facilities. New clocks can be declared to control simulation 
input and output activities . 

<DElay> declaration provides a means for specifying delay 
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time for delay facilities (old and new) . 

<INitialize> provides a means for initializing the output 
values of delays , registers , memories , element outputs , 
primary input signals, terminals and triggers with delays. 

<REad> enables input data values for various facilities 
in three modes: triggered, periodic and specific time. 

<LOad> provides a means for establishing the same input 
values repeatedly on specified facilities . The above three 
modes are possible. 

<OUtput> specifies the printing of the values of various 
facilities at various instants during simulation. The values 
are printed in octal (default) , binary, decimal or hexadecimal 
mode by setting the appropriate flag. 

<DUmp> dumps, the contents of specified memory locations 
at various instants during simulation. 

<STop> stops the simulation at a specified simulation 

time. 


<LIst> is used to assign a unique name to a list of fac- 
ilities and can be used when the same set of facilities are 
used in various declarations of the simulation deck. 

<SImulate> is used to separate different simulation runs 
in a simulation job. 

<FLag> enables the selection of various options for 
simulation runs by setting or resetting the associated flags. 

<TRigger> provides a means of declaring new facilities 
that can be used as triggering signals to control the 
simulation, without altering the DDL description. 
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5.12 DESIGN EXAMPLE [27] 


A MULTIPLIER unit, that calculates the product of two 
8-bit niitnbers is described in DDL. A listing of the deck used 
for simulating the MULTIPLIER system along with the simulation 
report is given on the following pages. The <FLag> declara- 
tion in the simulation deck specifies that all data-values 
specified without radix specification be interpreted in deci- 
mal (Flag 4) , and that output values be printed in binary 
(Flag 6) . The control unit MPY of the system waits idly in 
state SI until it receives a START command. A <INitialize> 
declaration is used to initialize the START signal to 1 and 
start the MULTIPLIER unit. On receivng the START command in 
state Si, the control unit proceeds to load the R register 
with the multiplicand obtained from the BUS and proceeds to 
state S2. In state S2 the B register is loaded with the 
multiplier obtained from the BUS. A triggered READ operation 
.with state terminal Si as the triggering signal is used to 
supply the BUS with the multiplicand. During simulation, 
whenever the control unit reaches state SI , the BUS is sup- 
plied with a new value of the multiplicand. The multiplier is 
supplied to the BUS in a similar manner with another triggered 
READ operation using state terminal S2 as the triggering sig- 
nal. After loading the multiplicand and the multiplier, the 
control unit proceeds to state S3. In state S3 the multipli- 
cand is added to the partial product, if the multipl- ier bit 
is logic 1. The control proceeds to state S4 in any case. 

The A and B registers are shifted right together and the mul- 
tiplication cycle counter MCOUNT is incremented. If the count 
has been completed, status line DONE is set to logic 1 and the 
control unit returns to its idle state SI . If not all bits of 
the multiplier have been tested, the control unit returns to 
state S3. 
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A triggering signal OUTTR defined using a <TRigger> de- 
claration is used in a triggered OUTPUT operation to control 
the printing of the values for MPY, MCOUNT, A, and B. These 
values are printed in binary on every trailing edge of the 
clock P signal. Another triggered OUTPUT operation using 
state terminal SI as the triggering signal controls the 
printing of the values for the multiplicand, multiplier and 
the final product. Note that these values are printed only 
once, i.e., when the final product is available, during a 
given multiplication operation. The two output lists printed 
with different frequency make the simulation report more 
informative and readable. Since no <CLock> declaration is 
included in the simulation deck, default values are used for 
period, pulse width and phase. Note that for a single 
simulation run a <SImulate> declaration is not required. Since 
an EOF condition is expected no explicit <STop> declaration is 
included in the simulation deck to terminate the simulation. 

$DDLTRN 

<C0> DESIGN OF A 8-BIT MULTIPLIER. 

<SY> MULTIPLIER ;<TI>P.<RE> A(0:8), B(8), R ( 8) ,MCOUNT ( 3) . 

<TE> START, BUS (8), DONE. 

<TE> SUM(8), C0UT(8>, CSUM{3) , CCOUT(3). 

<ID> CIN = COUT(2:8) "0D1 . 

<ID> COIN = CCOUT(2:8) "1D1 . 

<B0> GOUT = R*A{1;8) + R*CIN+A(1 ; 8) *CIN, 

SUM = R0A(1 ; 8) 0CIN, 

CCOUNT=MCOUNT*CCIN,CSUM=MCOUNT @ COIN, 
<AU> MPY(2) : P: 

<ST> SI (0) : START: R<-BUS, NCOUNT <-0,->S2. 

S2(1): B<-BUS, A<-C, ->S3 . 

S3{2); ?B(8) ? A<-COUT(l ) ” SUM.,->S4. 

S4{3): A(1:8)” B<-A"B(1:7), A(0)<-0, 

MCOUNT <-CSUM, ?*/MCOUNT?DONE=1 , 
->S1 ;->S3 
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SIMULATION. 


<FL> 4,6 > jUSE DECIMAL DATA AND PRINT OUTPUT 

[in BINARY FORf4AT. 

<IN> START/ 1 • [give A START COMMAND. 

<RE> SI/BUS/6, 10 • [data VALUES FOR THE MULTIPLICAND. 

<RE> S2/BUS/5,13- [DATA VALUES FOR THE MULTIPLIER. 

<TR> OUTTR/AP* [DEFINE A TRIGGER TO CONTROL PRINT- 

jlNG ON 

[trailing EDGE OF THE CLOCK. 

<OU> OUTTR/MPY,MCOUNT,A,B/, [PRINT MULTIPLICAND, 


[multiplier 


SI/8, BUS, A(1 :8) , B • 


& FINAL PRODUCT. 


$EOJ 


-digital 0ESIG‘i la. C'Ar.F 'LAT^fL 


SIMULATION RESULTS 

^rBSl’A - 07 . 030 X 76 1 SI 33 I 07 


03/29/76 


SII’ULATl.lN RUN 1 


000 oooonoooo no''Oon''o O'‘0ooooo •'ooo''Cnc oocooooo nr.oonooo 
ooo nonoooooo oo''0oo'>o 
ooo '■ooorOrto'’ ni'rf'oi''X 

000 •lOOOOOlin 00''0Ol''X 

001 '■ifloocooil ro"OnoiO 
OOX JOnOOOOXI O0'>0O0X0 

010 •'ooooonoi 1C7000"1 
oxci '■onoooill xnooool 

011 oononooix ii'-onono 
Oil t'onooooil U^OOOOO 
ion OOOOOOOOl lliooono 

100 oonocoool luonooo 

101 OOOOOOOO'' Ulinono 
101 oooonoooo liilno^o 
110 foooconon minooo 

110 000000007 01111070 

111 000000007 00111170 
111 000000007 OOllllOO 

000 oOOOOOOO" 00*11110 00(500110 Ooooomi oecoooon OOOllUO 

000 '-ooofOoo7 on-iiiio 
aOfi f oooooooo on7onrix 

oon '0OOC1717 00701171 

001 7ono*uioi 00700110 
ool roroouiol nononiio 
010 fonoconi" io7oooii 
010 '‘0OCO11O7 10700011 

on 73*300117 oiornooi 
on '•or H0O07 01700071 

100 OonOOlOOO 07100070 
ion 700001007 ociooooo 

101 loooooioo oo'imooo 

101 700000107 00rlOO70 
lit. '00000017 01)701070 

Uo fonono7i7 nr7oio7o 
in 700...30001 OO^OOIOO 
in roO')OOOOl 00*00170 

00* f 00000007 10700010 07001710 roooiini gocooooo lononoio 


.9 OF FILF REACHED [N J IPllT 
IMULATI'.N TER7I' AT6I' AT TIHr 


■ 0 OF SlM ILATIO 



6. COMPARISON 


All the available Hardware Descriptxon Languages satisfy 
the basic requirement of describing the hardware in a concise 
unambiguous and readable way. But, one language would be 
better than the other depending on the design environment. 

When desxgning systems of very low complexity, an HDL can be 
used only as a descriptxon media? this is because the HDL 
description usually is at a high-level and the designer can 
usually verify his design without resorting to the simulation. 
As the system complexity grows, it will be essential to verify 
the design at high levels using the HDL simulator, before 
proceedxng to the detailed design. 

After verifying the design through high-level simulation, 
the HDL description of the design can be used as an input to 
the programs , that generate the logic diagrams . This logic 
diagram data base serves as the starting point for the pro- 
grams that decide the physical aspects like, placement, 
routing, partition etc. of the integrated circuit design. 

The following five criteria were used in selectxng a 
suitable language: 

1 ) Activity 

2) Level of Description 

3) Software avaxlability and portability 

4) Ease of logic generatxon, and 

5) Modularity. 

ACTIVITY 

It is essential to choose a language which is being used 
elsewhere to receive the benefits of the extensions to the 
language. Most of the HDLs proposed do not have a translator 
and a simulator that is up-to-date and fairly versatile, 
though the language itself is versatile. All the four HDLs 
described, have been implemented at several locations and 
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there is a considerable amount of interest in making these 
HDLs more versatile, 

LEVEL OF DESCRIPTION : 

ISP is suitable for comparing systems at the instruction 
level. CDL is suitable at the register transfer level and 
does not have adequate txme and delay facilities. AHPL and 
DDL could be used very well in the circuit design work, since 
they are capable of description at and slightly below the 
register transfer level. 

SOFTWARE AVAILABILITY and PORTABILITY ; 

The ISP software is developed in BLISS on PDP-10 Computer 
system and is not portable. CDL software has many implementa- 
tions. Most of the software is in FORTRAN, with some essential 
routines in assembly language of the computer system it is 
implemented (IBM 360/370, UNIVAC 1110(6], CDC 6000 [5]). AHPL 
hardware compiler is written in SNOBOL and the simulator in 
FORTRAN on DEC- 10 and CDC 6400 systems. A few changes related 
to machine word length are required to make these operative on 
the other machines, DDL software is written in IFTRAN (Struct- 
ural FORTRAN) . An IFTRAN preprocessor is available. These 
programs also need some changes related to machine word 
length, to be operative on other machines. 

EASE OF LOGIC GENERATION : 

ISP is not suited to generating logic diagrams, CDL 
being a pure register transfer level language, does not tend 
itself very well to the logic generation. The AHPL hardware 
compiler provides a wiring list of the system consisting of 
gates and memory elements. DDL translator provides the 
Boolean functions for the system as an intermediate step in 
the translation process. These could be used to generate the 
logic diagrams . 
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MODULARITY ; 

High level modular description is possible with ISP. CDL 
is a one-level description language. The subroutine features 
of AHPL could be used to describe separate modules. DDL block 
structure is more closer to the hardware modularxty. 

From the above discussion, it is seen that AHPL and DDL 
are suitable for an integrated circuit design environment. 
However, the block structure of DDL, the right- to-left 
conventions of AHPL due to its origination from APL and the 
portability of DDL's FORTRAN software, makes DDL more suit- 
able. 



7 . CONCLUSIONS 


The characteristics of the four prominent HDLs are 
summarized. DDL was found to be most suitable among these four 
languages for an integrated circuit design environment. 

Since there are so many languages proposed [8] , it is 
very hard to perform a critical evaluation of their capabil- 
ities. Such a critical evaluation of the language capabilities 
might not be of much use, since the implementation issues more 
or less influence the selection of the language. The evalua- 
tion reported here caters more to the implementation aspects 
of the selected language. 

DDL translator and simulator are currently being imple- 
mented on the SEL-32 computer system of the electronics and 
controls laboratory of the Marshall Space Flight Center. The 
future work includes the development of procedures to generate 
logic diagrams from a DDL descripcion and integration of these 
procedure into the current automatic design sysuem. 

Three other languages that are heirarchic in nature, use 
a multi-level design philosophy allowing the designer to 
specify his design at any level of detail. They are: Language 
for Computer Desxgn [23] , an Hierarchical Language for the 
srructural description of Digital Systems [29] and a language 
for Automated Logic and System Design [30-32] , The RT-CAD 
research group at Carnegie-Mellon Uni.versiuy is using ISP in 
their register-transfer level design sutomanon [33] . 
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The languages described in the literature seem to be used 
mostly in the academic environment. Industrxal design groups 
usually make use of internal, proprietary languages. There 
seems to be a growing interest in HDLs , Recognizing the need 
for common notations and a standard language, a working group 
consisting of professionals in this area [34] has been set-up, 
which is trying to develop a consensus language. 
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